[ { "path": ".github/ISSUE_TEMPLATE/wiki-content-request.md", "content": "---\nname: Wiki content \nabout: Request a new content missing in the wiki \ntitle: ''\nlabels: 'feature'\nassignees: ''\n---\n\n## What content is missing?\n\n## Related content in the wiki\n\n## Other relevant resources \n\n" }, { "path": ".github/PULL_REQUEST_TEMPLATE.md", "content": "## Wiki PR Checklist\n\nThank you for contributing to the Protocol Wiki! Before you open a PR, make sure to read [information for contributors](https://epf.wiki/#/contributing) and take a look at following checklist:\n\n- [ ] Describe your changes, substitute this text with the information\n- [ ] If you are touching an existing piece of content, ask the [relevant maintainer](https://github.com/eth-protocol-fellows/protocol-studies/blob/maintainers/README.md#wiki-maintainers) for review\n- [ ] If you need feedback for your content from wider community, share the PR in our Discord\n- [ ] Review changes to ensure there are no typos, see instructions bellow\n\n\n" }, { "path": ".github/workflows/md-lint.yaml", "content": "name: Markdown linter\n\non:\n pull_request:\n branches:\n - main\njobs:\n lint:\n runs-on: ubuntu-latest\n steps:\n - uses: actions/checkout@v4\n - uses: DavidAnson/markdownlint-cli2-action@v15\n continue-on-error: true\n with:\n globs: |\n docs/wiki/*.md\n" }, { "path": ".github/workflows/spell-check.yml", "content": "name: 🥢 Spell check\n\non:\n pull_request_target:\n branches:\n - main\n\njobs:\n typo_check:\n name: 🥢 Spell check\n runs-on: ubuntu-latest\n permissions:\n contents: read\n pull-requests: write\n\n steps:\n # ⚠️ [Security Warning] Usage of `pull_request_target` along with fork ref checkout is a SECURITY RISK. ⚠️\n # > Generally speaking, when the PR contents are treated as passive data,\n # > i.e. not in a position of influence over the build/testing process, it is safe.\n # > But the repository owners must be extra careful not to trigger any script that may operate\n # > on PR controlled contents like in the case of npm install.\n # for more information, see: https://securitylab.github.com/resources/github-actions-preventing-pwn-requests/\n\n - name: Checkout code\n uses: actions/checkout@v4\n with:\n ref: ${{ github.event.pull_request.head.sha }}\n repository: ${{ github.event.pull_request.head.repo.full_name }}\n fetch-depth: 2\n\n - name: Install aspell\n run: sudo apt-get update && sudo apt-get install -y aspell\n\n - name: Find and check typos in Markdown files\n id: find_typos\n run: |\n echo \"Checking for typos...\"\n IFS=$'\\n'\n set -f\n for file in $(find . -name \"*.md\" ); do\n if [ ! -s \"$file\" ]; then\n continue\n fi\n echo \"Checking $file...\"\n # Get typos with line numbers using grep\n output=\"$(aspell --lang=en_US --mode=markdown --home-dir=. --personal=wordlist.txt --ignore-case=true --camel-case --add-sgml-skip name list <\"$file\")\"\n if [ $? -eq 0 ]; then\n if [[ -n \"$output\" ]]; then\n while IFS= read -r word; do\n # Find line numbers for each typo\n line_nums=$(grep -n \"$word\" \"$file\" | cut -d: -f1 | tr '\\n' ',' | sed 's/,$//')\n TYPOS+=\"- 📄 $file (line(s) $line_nums):\"\n TYPOS+=$'\\n'\n TYPOS+=\" 1. ❌ $word\"\n TYPOS+=$'\\n'\n done <<< \"$output\"\n fi\n else\n echo \"::error::aspell failed on $file\"\n exit 1\n fi\n done\n {\n echo 'TYPOS<> \"$GITHUB_ENV\"\n\n - name: Comment on pull request\n if: env.TYPOS != ''\n uses: actions/github-script@v7\n with:\n github-token: ${{ secrets.GITHUB_TOKEN }}\n script: |\n const author = '${{github.event.pull_request.user.login}}';\n const typos = `${{ env.TYPOS }}`;\n const body = `\n Hi @${author},\n\n ⚠️ Potential typos found in your pull request:\n\n ${typos}\n\n ## ℹ️ How to fix this error:\n 1. **If these are actual typos:**\n - Open the files at the specified line numbers and fix them\n\n 2. **If these are names or one-off nouns:**\n - Wrap them in \\`\\` tags\n - Example: \\`Alex Pereira\\`\n - Use this for people's names or unique terms that appear rarely\n\n 3. **If these are valid terms:**\n - Add them to \\`wordlist.txt\\` (one word per line)\n - Terms must be plain text without spaces/special chars\n - The list is case-insensitive\n\n 4. **If these are code terms:**\n - Wrap them in backticks (\\`) in your markdown\n\n ## ℹ️ Checking for typos locally\n 1. Install [aspell](https://www.gnu.org/software/aspell/) for your platform\n 2. Navigate to project root and run:\n \\`\\`\\`bash\n for f in **/*.md ; do echo $f ; aspell --lang=en_US --mode=markdown --home-dir=. --personal=wordlist.txt --ignore-case=true --camel-case --add-sgml-skip nospellcheck list < $f | sort | uniq -c ; done\n \\`\\`\\`\n\n [Learn more about wordlist format](http://aspell.net/man-html/Format-of-the-Personal-and-Replacement-Dictionaries.html)\n `;\n\n github.rest.issues.createComment({\n issue_number: context.issue.number,\n owner: context.repo.owner,\n repo: context.repo.repo,\n body: body\n });\n\n core.setFailed('🥢 Spell check found potential typos. See PR comment for details.');\n" }, { "path": ".gitignore", "content": "**/.DS_Store\n**/.DS_Store?\n**/.vscode\n**/.vscode?\n**/.obsidian\n**/.obsidian?\n**/.idea\n**/.idea?" }, { "path": "CODE_OF_CONDUCT.md", "content": "# Contributor Covenant Code of Conduct\n\n## Our Pledge\n\nWe as members, contributors, and leaders pledge to make participation in our\ncommunity a harassment-free experience for everyone, regardless of age, body\nsize, visible or invisible disability, ethnicity, sex characteristics, gender\nidentity and expression, level of experience, education, socio-economic status,\nnationality, personal appearance, race, religion, or sexual identity\nand orientation.\n\nWe pledge to act and interact in ways that contribute to an open, welcoming,\ndiverse, inclusive, and healthy community.\n\n## Our Standards\n\nExamples of behavior that contributes to a positive environment for our\ncommunity include:\n\n* Demonstrating empathy and kindness toward other people\n* Being respectful of differing opinions, viewpoints, and experiences\n* Giving and gracefully accepting constructive feedback\n* Accepting responsibility and apologizing to those affected by our mistakes,\n and learning from the experience\n* Focusing on what is best not just for us as individuals, but for the\n overall community\n\nExamples of unacceptable behavior include:\n\n* The use of sexualized language or imagery, and sexual attention or\n advances of any kind\n* Trolling, insulting or derogatory comments, and personal or political attacks\n* Public or private harassment\n* Publishing others' private information, such as a physical or email\n address, without their explicit permission\n* Other conduct which could reasonably be considered inappropriate in a\n professional setting\n\n## Enforcement Responsibilities\n\nCommunity leaders are responsible for clarifying and enforcing our standards of\nacceptable behavior and will take appropriate and fair corrective action in\nresponse to any behavior that they deem inappropriate, threatening, offensive,\nor harmful.\n\nCommunity leaders have the right and responsibility to remove, edit, or reject\ncomments, commits, code, wiki edits, issues, and other contributions that are\nnot aligned to this Code of Conduct, and will communicate reasons for moderation\ndecisions when appropriate.\n\n## Scope\n\nThis Code of Conduct applies within all community spaces, and also applies when\nan individual is officially representing the community in public spaces.\nExamples of representing our community include using an official e-mail address,\nposting via an official social media account, or acting as an appointed\nrepresentative at an online or offline event.\n\n## Enforcement\n\nInstances of abusive, harassing, or otherwise unacceptable behavior may be\nreported to the community leaders responsible for enforcement.\nAll complaints will be reviewed and investigated promptly and fairly.\n\nAll community leaders are obligated to respect the privacy and security of the\nreporter of any incident.\n\n## Enforcement Guidelines\n\nCommunity leaders will follow these Community Impact Guidelines in determining\nthe consequences for any action they deem in violation of this Code of Conduct:\n\n### 1. Correction\n\n**Community Impact**: Use of inappropriate language or other behavior deemed\nunprofessional or unwelcome in the community.\n\n**Consequence**: A private, written warning from community leaders, providing\nclarity around the nature of the violation and an explanation of why the\nbehavior was inappropriate. A public apology may be requested.\n\n### 2. Warning\n\n**Community Impact**: A violation through a single incident or series\nof actions.\n\n**Consequence**: A warning with consequences for continued behavior. No\ninteraction with the people involved, including unsolicited interaction with\nthose enforcing the Code of Conduct, for a specified period of time. This\nincludes avoiding interactions in community spaces as well as external channels\nlike social media. Violating these terms may lead to a temporary or\npermanent ban.\n\n### 3. Temporary Ban\n\n**Community Impact**: A serious violation of community standards, including\nsustained inappropriate behavior.\n\n**Consequence**: A temporary ban from any sort of interaction or public\ncommunication with the community for a specified period of time. No public or\nprivate interaction with the people involved, including unsolicited interaction\nwith those enforcing the Code of Conduct, is allowed during this period.\nViolating these terms may lead to a permanent ban.\n\n### 4. Permanent Ban\n\n**Community Impact**: Demonstrating a pattern of violation of community\nstandards, including sustained inappropriate behavior, harassment of an\nindividual, or aggression toward or disparagement of classes of individuals.\n\n**Consequence**: A permanent ban from any sort of public interaction within\nthe community.\n\n## Attribution\n\nThis Code of Conduct is adapted from the [Contributor Covenant]([https://www.contributor-covenant.org),\nversion 2.0, available at\n[https://www.contributor-covenant.org/version/2/0/code_of_conduct.html][v2.0].\n\nCommunity Impact Guidelines were inspired by\n[Mozilla's code of conduct enforcement ladder][Mozilla CoC].\n\nFor answers to common questions about this code of conduct, see the FAQ at\n[https://www.contributor-covenant.org/faq][FAQ]. Translations are available\nat [https://www.contributor-covenant.org/translations][translations].\n\n[v2.0]: https://www.contributor-covenant.org/version/2/0/code_of_conduct.html\n[Mozilla CoC]: https://github.com/mozilla/diversity\n[FAQ]: https://www.contributor-covenant.org/faq\n[translations]: https://www.contributor-covenant.org/translations\n" }, { "path": "LICENSE", "content": "Creative Commons Attribution-ShareAlike 4.0 International Public\nLicense\n\nBy exercising the Licensed Rights (defined below), You accept and agree\nto be bound by the terms and conditions of this Creative Commons\nAttribution-ShareAlike 4.0 International Public License (\"Public\nLicense\"). To the extent this Public License may be interpreted as a\ncontract, You are granted the Licensed Rights in consideration of Your\nacceptance of these terms and conditions, and the Licensor grants You\nsuch rights in consideration of benefits the Licensor receives from\nmaking the Licensed Material available under these terms and\nconditions.\n\n\nSection 1 -- Definitions.\n\n a. Adapted Material means material subject to Copyright and Similar\n Rights that is derived from or based upon the Licensed Material\n and in which the Licensed Material is translated, altered,\n arranged, transformed, or otherwise modified in a manner requiring\n permission under the Copyright and Similar Rights held by the\n Licensor. For purposes of this Public License, where the Licensed\n Material is a musical work, performance, or sound recording,\n Adapted Material is always produced where the Licensed Material is\n synched in timed relation with a moving image.\n\n b. Adapter's License means the license You apply to Your Copyright\n and Similar Rights in Your contributions to Adapted Material in\n accordance with the terms and conditions of this Public License.\n\n c. BY-SA Compatible License means a license listed at\n creativecommons.org/compatiblelicenses, approved by Creative\n Commons as essentially the equivalent of this Public License.\n\n d. Copyright and Similar Rights means copyright and/or similar rights\n closely related to copyright including, without limitation,\n performance, broadcast, sound recording, and Sui Generis Database\n Rights, without regard to how the rights are labeled or\n categorized. For purposes of this Public License, the rights\n specified in Section 2(b)(1)-(2) are not Copyright and Similar\n Rights.\n\n e. Effective Technological Measures means those measures that, in the\n absence of proper authority, may not be circumvented under laws\n fulfilling obligations under Article 11 of the WIPO Copyright\n Treaty adopted on December 20, 1996, and/or similar international\n agreements.\n\n f. Exceptions and Limitations means fair use, fair dealing, and/or\n any other exception or limitation to Copyright and Similar Rights\n that applies to Your use of the Licensed Material.\n\n g. License Elements means the license attributes listed in the name\n of a Creative Commons Public License. The License Elements of this\n Public License are Attribution and ShareAlike.\n\n h. Licensed Material means the artistic or literary work, database,\n or other material to which the Licensor applied this Public\n License.\n\n i. Licensed Rights means the rights granted to You subject to the\n terms and conditions of this Public License, which are limited to\n all Copyright and Similar Rights that apply to Your use of the\n Licensed Material and that the Licensor has authority to license.\n\n j. Licensor means the individual(s) or entity(ies) granting rights\n under this Public License.\n\n k. Share means to provide material to the public by any means or\n process that requires permission under the Licensed Rights, such\n as reproduction, public display, public performance, distribution,\n dissemination, communication, or importation, and to make material\n available to the public including in ways that members of the\n public may access the material from a place and at a time\n individually chosen by them.\n\n l. Sui Generis Database Rights means rights other than copyright\n resulting from Directive 96/9/EC of the European Parliament and of\n the Council of 11 March 1996 on the legal protection of databases,\n as amended and/or succeeded, as well as other essentially\n equivalent rights anywhere in the world.\n\n m. You means the individual or entity exercising the Licensed Rights\n under this Public License. Your has a corresponding meaning.\n\n\nSection 2 -- Scope.\n\n a. License grant.\n\n 1. Subject to the terms and conditions of this Public License,\n the Licensor hereby grants You a worldwide, royalty-free,\n non-sublicensable, non-exclusive, irrevocable license to\n exercise the Licensed Rights in the Licensed Material to:\n\n a. reproduce and Share the Licensed Material, in whole or\n in part; and\n\n b. produce, reproduce, and Share Adapted Material.\n\n 2. Exceptions and Limitations. For the avoidance of doubt, where\n Exceptions and Limitations apply to Your use, this Public\n License does not apply, and You do not need to comply with\n its terms and conditions.\n\n 3. Term. The term of this Public License is specified in Section\n 6(a).\n\n 4. Media and formats; technical modifications allowed. The\n Licensor authorizes You to exercise the Licensed Rights in\n all media and formats whether now known or hereafter created,\n and to make technical modifications necessary to do so. The\n Licensor waives and/or agrees not to assert any right or\n authority to forbid You from making technical modifications\n necessary to exercise the Licensed Rights, including\n technical modifications necessary to circumvent Effective\n Technological Measures. For purposes of this Public License,\n simply making modifications authorized by this Section 2(a)\n (4) never produces Adapted Material.\n\n 5. Downstream recipients.\n\n a. Offer from the Licensor -- Licensed Material. Every\n recipient of the Licensed Material automatically\n receives an offer from the Licensor to exercise the\n Licensed Rights under the terms and conditions of this\n Public License.\n\n b. Additional offer from the Licensor -- Adapted Material.\n Every recipient of Adapted Material from You\n automatically receives an offer from the Licensor to\n exercise the Licensed Rights in the Adapted Material\n under the conditions of the Adapter's License You apply.\n\n c. No downstream restrictions. You may not offer or impose\n any additional or different terms or conditions on, or\n apply any Effective Technological Measures to, the\n Licensed Material if doing so restricts exercise of the\n Licensed Rights by any recipient of the Licensed\n Material.\n\n 6. No endorsement. Nothing in this Public License constitutes or\n may be construed as permission to assert or imply that You\n are, or that Your use of the Licensed Material is, connected\n with, or sponsored, endorsed, or granted official status by,\n the Licensor or others designated to receive attribution as\n provided in Section 3(a)(1)(A)(i).\n\n b. Other rights.\n\n 1. Moral rights, such as the right of integrity, are not\n licensed under this Public License, nor are publicity,\n privacy, and/or other similar personality rights; however, to\n the extent possible, the Licensor waives and/or agrees not to\n assert any such rights held by the Licensor to the limited\n extent necessary to allow You to exercise the Licensed\n Rights, but not otherwise.\n\n 2. Patent and trademark rights are not licensed under this\n Public License.\n\n 3. To the extent possible, the Licensor waives any right to\n collect royalties from You for the exercise of the Licensed\n Rights, whether directly or through a collecting society\n under any voluntary or waivable statutory or compulsory\n licensing scheme. In all other cases the Licensor expressly\n reserves any right to collect such royalties.\n\n\nSection 3 -- License Conditions.\n\nYour exercise of the Licensed Rights is expressly made subject to the\nfollowing conditions.\n\n a. Attribution.\n\n 1. If You Share the Licensed Material (including in modified\n form), You must:\n\n a. retain the following if it is supplied by the Licensor\n with the Licensed Material:\n\n i. identification of the creator(s) of the Licensed\n Material and any others designated to receive\n attribution, in any reasonable manner requested by\n the Licensor (including by pseudonym if\n designated);\n\n ii. a copyright notice;\n\n iii. a notice that refers to this Public License;\n\n iv. a notice that refers to the disclaimer of\n warranties;\n\n v. a URI or hyperlink to the Licensed Material to the\n extent reasonably practicable;\n\n b. indicate if You modified the Licensed Material and\n retain an indication of any previous modifications; and\n\n c. indicate the Licensed Material is licensed under this\n Public License, and include the text of, or the URI or\n hyperlink to, this Public License.\n\n 2. You may satisfy the conditions in Section 3(a)(1) in any\n reasonable manner based on the medium, means, and context in\n which You Share the Licensed Material. For example, it may be\n reasonable to satisfy the conditions by providing a URI or\n hyperlink to a resource that includes the required\n information.\n\n 3. If requested by the Licensor, You must remove any of the\n information required by Section 3(a)(1)(A) to the extent\n reasonably practicable.\n\n b. ShareAlike.\n\n In addition to the conditions in Section 3(a), if You Share\n Adapted Material You produce, the following conditions also apply.\n\n 1. The Adapter's License You apply must be a Creative Commons\n license with the same License Elements, this version or\n later, or a BY-SA Compatible License.\n\n 2. You must include the text of, or the URI or hyperlink to, the\n Adapter's License You apply. You may satisfy this condition\n in any reasonable manner based on the medium, means, and\n context in which You Share Adapted Material.\n\n 3. You may not offer or impose any additional or different terms\n or conditions on, or apply any Effective Technological\n Measures to, Adapted Material that restrict exercise of the\n rights granted under the Adapter's License You apply.\n\n\nSection 4 -- Sui Generis Database Rights.\n\nWhere the Licensed Rights include Sui Generis Database Rights that\napply to Your use of the Licensed Material:\n\n a. for the avoidance of doubt, Section 2(a)(1) grants You the right\n to extract, reuse, reproduce, and Share all or a substantial\n portion of the contents of the database;\n\n b. if You include all or a substantial portion of the database\n contents in a database in which You have Sui Generis Database\n Rights, then the database in which You have Sui Generis Database\n Rights (but not its individual contents) is Adapted Material,\n including for purposes of Section 3(b); and\n\n c. You must comply with the conditions in Section 3(a) if You Share\n all or a substantial portion of the contents of the database.\n\nFor the avoidance of doubt, this Section 4 supplements and does not\nreplace Your obligations under this Public License where the Licensed\nRights include other Copyright and Similar Rights.\n\n\nSection 5 -- Disclaimer of Warranties and Limitation of Liability.\n\n a. UNLESS OTHERWISE SEPARATELY UNDERTAKEN BY THE LICENSOR, TO THE\n EXTENT POSSIBLE, THE LICENSOR OFFERS THE LICENSED MATERIAL AS-IS\n AND AS-AVAILABLE, AND MAKES NO REPRESENTATIONS OR WARRANTIES OF\n ANY KIND CONCERNING THE LICENSED MATERIAL, WHETHER EXPRESS,\n IMPLIED, STATUTORY, OR OTHER. THIS INCLUDES, WITHOUT LIMITATION,\n WARRANTIES OF TITLE, MERCHANTABILITY, FITNESS FOR A PARTICULAR\n PURPOSE, NON-INFRINGEMENT, ABSENCE OF LATENT OR OTHER DEFECTS,\n ACCURACY, OR THE PRESENCE OR ABSENCE OF ERRORS, WHETHER OR NOT\n KNOWN OR DISCOVERABLE. WHERE DISCLAIMERS OF WARRANTIES ARE NOT\n ALLOWED IN FULL OR IN PART, THIS DISCLAIMER MAY NOT APPLY TO YOU.\n\n b. TO THE EXTENT POSSIBLE, IN NO EVENT WILL THE LICENSOR BE LIABLE\n TO YOU ON ANY LEGAL THEORY (INCLUDING, WITHOUT LIMITATION,\n NEGLIGENCE) OR OTHERWISE FOR ANY DIRECT, SPECIAL, INDIRECT,\n INCIDENTAL, CONSEQUENTIAL, PUNITIVE, EXEMPLARY, OR OTHER LOSSES,\n COSTS, EXPENSES, OR DAMAGES ARISING OUT OF THIS PUBLIC LICENSE OR\n USE OF THE LICENSED MATERIAL, EVEN IF THE LICENSOR HAS BEEN\n ADVISED OF THE POSSIBILITY OF SUCH LOSSES, COSTS, EXPENSES, OR\n DAMAGES. WHERE A LIMITATION OF LIABILITY IS NOT ALLOWED IN FULL OR\n IN PART, THIS LIMITATION MAY NOT APPLY TO YOU.\n\n c. The disclaimer of warranties and limitation of liability provided\n above shall be interpreted in a manner that, to the extent\n possible, most closely approximates an absolute disclaimer and\n waiver of all liability.\n\n\nSection 6 -- Term and Termination.\n\n a. This Public License applies for the term of the Copyright and\n Similar Rights licensed here. However, if You fail to comply with\n this Public License, then Your rights under this Public License\n terminate automatically.\n\n b. Where Your right to use the Licensed Material has terminated under\n Section 6(a), it reinstates:\n\n 1. automatically as of the date the violation is cured, provided\n it is cured within 30 days of Your discovery of the\n violation; or\n\n 2. upon express reinstatement by the Licensor.\n\n For the avoidance of doubt, this Section 6(b) does not affect any\n right the Licensor may have to seek remedies for Your violations\n of this Public License.\n\n c. For the avoidance of doubt, the Licensor may also offer the\n Licensed Material under separate terms or conditions or stop\n distributing the Licensed Material at any time; however, doing so\n will not terminate this Public License.\n\n d. Sections 1, 5, 6, 7, and 8 survive termination of this Public\n License.\n\n\nSection 7 -- Other Terms and Conditions.\n\n a. The Licensor shall not be bound by any additional or different\n terms or conditions communicated by You unless expressly agreed.\n\n b. Any arrangements, understandings, or agreements regarding the\n Licensed Material not stated herein are separate from and\n independent of the terms and conditions of this Public License.\n\n\nSection 8 -- Interpretation.\n\n a. For the avoidance of doubt, this Public License does not, and\n shall not be interpreted to, reduce, limit, restrict, or impose\n conditions on any use of the Licensed Material that could lawfully\n be made without permission under this Public License.\n\n b. To the extent possible, if any provision of this Public License is\n deemed unenforceable, it shall be automatically reformed to the\n minimum extent necessary to make it enforceable. If the provision\n cannot be reformed, it shall be severed from this Public License\n without affecting the enforceability of the remaining terms and\n conditions.\n\n c. No term or condition of this Public License will be waived and no\n failure to comply consented to unless expressly agreed to by the\n Licensor.\n\n d. Nothing in this Public License constitutes or may be interpreted\n as a limitation upon, or waiver of, any privileges and immunities\n that apply to the Licensor or You, including from the legal\n processes of any jurisdiction or authority.\n\n\n=======================================================================\n\nCreative Commons is not a party to its public\nlicenses. Notwithstanding, Creative Commons may elect to apply one of\nits public licenses to material it publishes and in those instances\nwill be considered the “Licensor.” The text of the Creative Commons\npublic licenses is dedicated to the public domain under the CC0 Public\nDomain Dedication. Except for the limited purpose of indicating that\nmaterial is shared under a Creative Commons public license or as\notherwise permitted by the Creative Commons policies published at\ncreativecommons.org/policies, Creative Commons does not authorize the\nuse of the trademark \"Creative Commons\" or any other trademark or logo\nof Creative Commons without its prior written consent including,\nwithout limitation, in connection with any unauthorized modifications\nto any of its public licenses or any other arrangements,\nunderstandings, or agreements concerning use of licensed material. For\nthe avoidance of doubt, this paragraph does not form part of the\npublic licenses.\n\nCreative Commons may be contacted at creativecommons.org.\n\n" }, { "path": "README.md", "content": "# Ethereum Protocol Fellowship Study Group (EPFsg)\r\n\r\nThis repository is dedicated to coordination and developing a knowledge base for the EPFsg. It hosts the Protocol Wiki, a community effort to build a technical knowledge base about the Ethereum core protocol.\r\n\r\n[Learn more about the EPF study group](https://epf.wiki/#/eps/intro) and dive into the [wiki content](https://epf.wiki/#/README?id=protocol-wiki) to study the protocol. \r\n\r\n## Protocol Studies Wiki\r\n\r\nYou can visit the wiki at https://epf.wiki or head to `/docs` for the source.\r\n\r\n[Join us](https://discord.com/invite/addwpQbhpq) to learn about the protocol and start [contributing](/docs/contributing.md).\r\n\r\n![](/docs/images/epf7_hero.png)\r\n" }, { "path": "check_typos.sh", "content": "#!/bin/bash\n\n# Ensure TYPOS variable is empty to start\nTYPOS=\"\"\n\necho \"🔍 Checking for typos...\"\n\n# Use -v to ensure aspell is installed before running\nif ! command -v aspell &>/dev/null; then\n echo \"❌ Error: 'aspell' is not installed. (Hint: brew install aspell / apt install aspell)\"\n exit 1\nfi\n\n# Set Internal Field Separator to handle filenames with spaces\nIFS=$'\\n'\nset -f\n\nfor file in $(find . -name \"*.md\"); do\n if [ ! -s \"$file\" ]; then\n continue\n fi\n\n echo \"Reading: $file\"\n\n # Get typos list from aspell\n output=\"$(aspell list --lang=en_US --mode=markdown --home-dir=. --personal=./wordlist.txt --ignore-case=true --camel-case --add-sgml-skip name list <\"$file\")\"\n\n if [ $? -eq 0 ]; then\n if [[ -n \"$output\" ]]; then\n # Use sort -u to avoid repeating the same word multiple times\n unique_typos=$(echo \"$output\" | sort -u)\n\n while read -r word; do\n # Find line numbers\n line_nums=$(grep -nwi \"$word\" \"$file\" | cut -d: -f1 | tr '\\n' ',' | sed 's/,$//')\n\n TYPOS+=\"- 📄 $file (line(s) $line_nums):\"$'\\n'\n TYPOS+=\" ❌ $word\"$'\\n'\n done <<<\"$unique_typos\"\n fi\n else\n echo \"::error::aspell failed on $file\"\n exit 1\n fi\ndone\n\n# Output the results to the terminal\nif [[ -z \"$TYPOS\" ]]; then\n echo \"✅ No typos found!\"\nelse\n echo -e \"\\n--- Spelling Report ---\\n\"\n echo \"$TYPOS\"\nfi\n" }, { "path": "docs/.nojekyll", "content": "" }, { "path": "docs/CNAME", "content": "epf.wiki" }, { "path": "docs/_footer.md", "content": "---\nEPF Wiki initiated by EF Protocol Support and maintained by EPFsg community. \"CC
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International..\n" }, { "path": "docs/_navbar.md", "content": "* [Home](readme.md)\n* [Study Group](/eps/intro.md)\n* [Protocol Wiki](/wiki/wiki-intro.md)\n* [Contribute](contributing.md)\n" }, { "path": "docs/_sidebar.md", "content": "- [Home](readme.md)\n- [Contributing](contributing.md)\n- **Study Group**\n- [Join the studies](/eps/intro.md)\n- [Study Group archive](/eps/archive.md)\n- **Protocol Wiki**\n- The Protocol\n - [Prehistory](/wiki/protocol/prehistory.md)\n - [Architecture](/wiki/protocol/architecture.md)\n - [Design rationale](/wiki/protocol/design-rationale.md)\n - [Evolution](/wiki/protocol/history.md)\n- Execution Layer\n - [EL Specs](/wiki/EL/el-specs.md)\n - [Client architecture](/wiki/EL/el-architecture.md)\n - [Engine API](/wiki/EL/engine-api.md)\n - [EL Clients](/wiki/EL/el-clients.md)\n - [Besu](/wiki/EL/clients/besu.md)\n - [Reth](/wiki/EL/clients/reth.md)\n - [EVM](/wiki/EL/evm.md)\n - [Precompiled Contracts](/wiki/EL/precompiled-contracts.md)\n - [Block Building](/wiki/EL/block-production.md)\n - [Data Structures](/wiki/EL/data-structures.md)\n - [Summary](/wiki/EL/el-data-structures-summary.md)\n - [Transaction anatomy](/wiki/EL/transaction.md)\n - [JSON-RPC](/wiki/EL/JSON-RPC.md)\n - [DevP2P](/wiki/EL/devp2p.md)\n - [RLP Serialization](/wiki/EL/RLP.md)\n - [EOF](/wiki/EL/eof.md)\n- Consensus Layer\n - [Overview](/wiki/CL/overview.md)\n - [Client architecture](/wiki/CL/cl-architecture.md)\n - [CL Networking](/wiki/CL/cl-networking.md)\n - [CL Specs](/wiki/CL/cl-specs.md)\n - [Beacon API](/wiki/CL/beacon-api.md)\n - [CL Clients](/wiki/CL/cl-clients.md)\n - [SSZ Serialization](/wiki/CL/SSZ.md)\n - [Merkleization](/wiki/CL/merkleization.md)\n - [Weak Subjectivity](/wiki/CL/syncing.md)\n- Development\n - [Core development](/wiki/dev/core-development.md)\n - [Coordination](/wiki/dev/pm.md)\n - [Dev Resources](/wiki/dev/cs-resources.md)\n- Testing and security\n - [Testing overview](/wiki/testing/overview.md)\n - [Incidents](/wiki/testing/incidents.md)\n - [Hive](/wiki/testing/hive.md)\n - [Kurtosis](/wiki/testing/kurtosis.md)\n - [Formal verification](/wiki/testing/formal-verification.md)\n- Research\n - [Roadmap overview](/wiki/research/roadmap.md)\n - [Scaling](/wiki/research/scaling/scaling.md)\n - [Core Changes](/wiki/research/scaling/core-changes/core-changes.md)\n - [EIP-4844](/wiki/research/scaling/core-changes/eip-4844.md)\n - [MEV](/wiki/research/PBS/mev.md)\n - [MEV-boost](/wiki/research/PBS/mev-boost.md)\n - [PBS](/wiki/research/PBS/pbs.md)\n - [ePBS](/wiki/research/PBS/ePBS.md)\n - [ePBS Design Specs](/wiki/research/PBS/ePBS-Specs.md)\n - [PTC](/wiki/research/PBS/PTC.md)\n - [PEPC](/wiki/research/PBS/PEPC.md)\n - [TBHL](/wiki/research/PBS/TBHL.md)\n - [ET](/wiki/research/PBS/ET.md)\n - [eODS](/wiki/research/eODS.md)\n - [PeerDAS](/wiki/research/peerdas.md)\n - [FCR](/wiki/research/FCR/FCR.md)\n - [History Expiry](/wiki/research/history-expiry/history-expiry.md)\n - Preconfirmations\n - [Preconfirmations](/wiki/research/Preconfirmations/Preconfirmations.md)\n - [Based Sequencing with Preconfs](/wiki/research/Preconfirmations/BasedSequencingPreconfs.md)\n - [Light clients](/wiki/research/light-clients.md)\n - Account abstraction\n - [EIP-7702](/wiki/research/account-abstraction/eip-7702.md)\n- [Cryptography](/wiki/Cryptography/intro.md)\n - [ECDSA](/wiki/Cryptography/ecdsa.md)\n - [BLS](/wiki/Cryptography/bls.md)\n - [Keccak256](/wiki/Cryptography/keccak256.md)\n - Commitments\n - [KZG](/wiki/Cryptography/KZG.md)\n - [Post-Quantum Cryptography](/wiki/Cryptography/post-quantum-cryptography.md)\n- [Protocol Fellowship](/wiki/epf.md)\n- [Pectra FAQ](/wiki/pectra-faq.md)\n\n- **Wiki Info**\n - [GitHub Repository](https://github.com/eth-protocol-fellows/protocol-studies)\n\n
\n \n
\n" }, { "path": "docs/assets/css/custom.css", "content": "/* File for custom CSS\n\n/* CSS to better visually match Docsify pages within Canvas LMS (uncomment to use) */\n/*\n@import url('https://fonts.googleapis.com/css2?family=Lato:ital,wght@0,400;0,700;1,400;1,700&display=swap');\n\nbody .markdown-section {\n font-family: \"Lato Extended\",\"Lato\",\"Helvetica Neue\",Arial,sans-serif;\n line-height: 1.4;\n font-size: 16px;\n}\n*/\n\n/* Link colors to match SFU branding visual styling (uncomment to use) */\n/*\n:root {\n --link-color: #CC0633!important;\n --link-text-decoration: none!important;\n --link-text-decoration--hover: underline!important;\n\n --sidebar-name-color: #CC0633!important;\n --sidebar-nav-link-color: #757575!important;\n --sidebar-nav-link-color--active: #CC0633!important;\n --sidebar-nav-link-border-color--active: #CC0633!important;\n\n --sidebar-nav-pagelink-background--active:\n no-repeat 0px center / 5px 6px\n linear-gradient(225deg, transparent 2.75px, #CC0633 2.75px 4.25px, transparent 4.25px),\n no-repeat 5px center / 5px 6px\n linear-gradient(135deg, transparent 2.75px, #CC0633 2.75px 4.25px, transparent 4.25px)!important;\n --sidebar-nav-pagelink-background--collapse:\n no-repeat 2px calc(50% - 2.5px) / 6px 5px\n linear-gradient(45deg, transparent 2.75px, #CC0633 2.75px 4.25px, transparent 4px),\n no-repeat 2px calc(50% + 2.5px) / 6px 5px\n linear-gradient(135deg, transparent 2.75px, #CC0633 2.75px 4.25px, transparent 4px)!important;\n --sidebar-nav-pagelink-background--loaded:\n no-repeat 0px center / 5px 6px\n linear-gradient(225deg, transparent 2.75px, #CC0633 2.75px 4.25px, transparent 4.25px),\n no-repeat 5px center / 5px 6px\n linear-gradient(135deg, transparent 2.75px, #CC0633 2.75px 4.25px, transparent 4.25px)!important;\n\n --navbar-root-color: #757575!important;\n --navbar-root-color--active: #CC0633!important;\n\n --blockquote-border-color: #757b7f!important;\n\n --pagination-title-color: #CC0633!important;\n}\n*/\n\n/* Dark mode colours to match SFU branding visual styling for use with light + dark theme (uncomment to use) */\n/*\n@media (prefers-color-scheme: dark) {\n:root {\n\n --link-color: #EA7688!important;\n --link-text-decoration: none!important;\n --link-text-decoration--hover: underline!important;\n\n --sidebar-name-color: #EA7688!important;\n --sidebar-nav-link-color: #B2B4B4!important;\n --sidebar-nav-link-color--active: #EA7688!important;\n --sidebar-nav-link-border-color--active: #EA7688!important;\n\n --sidebar-nav-pagelink-background--active:\n no-repeat 0px center / 5px 6px linear-gradient(225deg, transparent 2.75px, #EA7688 2.75px 4.25px, transparent 4.25px), no-repeat 5px center / 5px 6px linear-gradient(135deg, transparent 2.75px, #EA7688 2.75px 4.25px, transparent 4.25px)!important;\n --sidebar-nav-pagelink-background--collapse:\n no-repeat 2px calc(50% - 2.5px) / 6px 5px linear-gradient(45deg, transparent 2.75px, #EA7688 2.75px 4.25px, transparent 4px), no-repeat 2px calc(50% + 2.5px) / 6px 5px linear-gradient(135deg, transparent 2.75px, #EA7688 2.75px 4.25px, transparent 4px)!important;\n --sidebar-nav-pagelink-background--loaded:\n no-repeat 0px center / 5px 6px linear-gradient(225deg, transparent 2.75px, #EA7688 2.75px 4.25px, transparent 4.25px), no-repeat 5px center / 5px 6px linear-gradient(135deg, transparent 2.75px, #EA7688 2.75px 4.25px, transparent 4.25px)!important;\n\n --navbar-root-color: #B2B4B4!important;\n --navbar-root-color--active: #EA7688!important;\n\n --blockquote-border-color: #757B7F!important;\n\n --pagination-title-color: #EA7688!important;\n }\n}\n*/\n\n/* Link colors to match visual styling of Moodle LMS (uncomment to use) */\n/*\n:root {\n --link-color: #0F6CBF!important;\n\n --sidebar-name-color: #0F6CBF!important;\n --sidebar-nav-link-color--active: #0F6CBF!important;\n --sidebar-nav-link-border-color--active: #0F6CBF!important;\n\n --sidebar-nav-pagelink-background--active:\n no-repeat 0px center / 5px 6px\n linear-gradient(225deg, transparent 2.75px, #0F6CBF 2.75px 4.25px, transparent 4.25px),\n no-repeat 5px center / 5px 6px\n linear-gradient(135deg, transparent 2.75px, #0F6CBF 2.75px 4.25px, transparent 4.25px)!important;\n --sidebar-nav-pagelink-background--collapse:\n no-repeat 2px calc(50% - 2.5px) / 6px 5px\n linear-gradient(45deg, transparent 2.75px, #0F6CBF 2.75px 4.25px, transparent 4px),\n no-repeat 2px calc(50% + 2.5px) / 6px 5px\n linear-gradient(135deg, transparent 2.75px, #0F6CBF 2.75px 4.25px, transparent 4px)!important;\n --sidebar-nav-pagelink-background--loaded:\n no-repeat 0px center / 5px 6px\n linear-gradient(225deg, transparent 2.75px, #0F6CBF 2.75px 4.25px, transparent 4.25px),\n no-repeat 5px center / 5px 6px\n linear-gradient(135deg, transparent 2.75px, #0F6CBF 2.75px 4.25px, transparent 4.25px)!important;\n --navbar-root-color--active: #0F6CBF!important;\n\n --blockquote-border-color: #0F6CBF!important;\n\n --pagination-title-color: #0F6CBF!important;\n}\n*/\n\n/* Link colors to match visual styling of Sakai LMS (uncomment to use) */\n/*\n:root {\n --link-color: #0B1660!important;\n\n --sidebar-name-color: #0B1660!important;\n --sidebar-nav-link-color--active: #0B1660!important;\n --sidebar-nav-link-border-color--active: #0B1660!important;\n\n --sidebar-nav-pagelink-background--active:\n no-repeat 0px center / 5px 6px\n linear-gradient(225deg, transparent 2.75px, #0B1660 2.75px 4.25px, transparent 4.25px),\n no-repeat 5px center / 5px 6px\n linear-gradient(135deg, transparent 2.75px, #0B1660 2.75px 4.25px, transparent 4.25px)!important;\n --sidebar-nav-pagelink-background--collapse:\n no-repeat 2px calc(50% - 2.5px) / 6px 5px\n linear-gradient(45deg, transparent 2.75px, #0B1660 2.75px 4.25px, transparent 4px),\n no-repeat 2px calc(50% + 2.5px) / 6px 5px\n linear-gradient(135deg, transparent 2.75px, #0B1660 2.75px 4.25px, transparent 4px)!important;\n --sidebar-nav-pagelink-background--loaded:\n no-repeat 0px center / 5px 6px\n linear-gradient(225deg, transparent 2.75px, #0B1660 2.75px 4.25px, transparent 4.25px),\n no-repeat 5px center / 5px 6px\n linear-gradient(135deg, transparent 2.75px, #0B1660 2.75px 4.25px, transparent 4.25px)!important;\n\n --navbar-root-color--active: #0B1660!important;\n --navbar-root-color--active: #0B1660!important;\n\n --blockquote-border-color: #0B1660!important;\n \n --pagination-title-color: #0B1660!important;\n}\n*/\n\n/* CSS to better visually match Docsify pages within Sakai LMS (uncomment to use) */\n/*\n@import url('https://fonts.googleapis.com/css2?family=Open+Sans:ital,wght@0,400;0,600;0,700;1,400;1,600;1,700&display=swap');\n\nbody .markdown-section {\n font-family: \"Open Sans\",sans-serif;\n line-height: 1.3;\n font-size: 14px;\n}\n*/\n\n/* \n ################################\n || ||\n || 🎨 EPF.WIKI Theme ||\n || ||\n ################################\n*/\n\n:root {\n --base-background-color: #1c153b;\n --sidebar-name-color: #ba9afd;\n --sidebar-background: #190c39;\n --sidebar-toggle-background: #190c39;\n --navbar-root-color--active: #ba9afd;\n --search-input-background-color: #2d1763;\n --table-row-odd-background: #2d1763;\n --base-color: #fff;\n --heading-color: #fff;\n --primary-text-color: #d3d3d3;\n\n /* blockquote*/\n --blockquote-background: #2d1763;\n --blockquote-color: var(--primary-text-color);\n --blockquote-border-color: #ba9afd;\n\n /* link */\n --link-color: #ba9afd;\n\n /* text */\n}\n\nbody {\n color: #fff;\n}\n\nsection.content , .markdown-section code{\n color: var(--primary-text-color);\n}\n\n/* sidebar */\nli.file,\nli.folder {\n padding: 8px 15px;\n margin-bottom: 4px;\n}\nli.file p,\nli.folder p {\n margin: 0;\n}\n\nli.folder.active,\nli.folder:hover,\nli.folder.open,\nli.file.active,\nli.file:hover,\nli.file.open {\n border-radius: 5px;\n background: #2d1763;\n}\n\n.app-sub-sidebar li.file,\n.app-sub-sidebar li.folder {\n padding: 0;\n margin: 0;\n animation: tabFade 0.5s;\n}\n\nli.folder strong,\nli.file strong {\n padding: 10px 0;\n display: block;\n border-bottom: 1px dashed #a278ff;\n}\n\nli.folder > ul > li.file {\n padding: 0;\n}\n.sidebar-nav ul.app-sub-sidebar a {\n border: none;\n border-left: 4px solid #fff;\n padding-left: 8px;\n}\n\n.sidebar-nav ul.app-sub-sidebar li.active > a,\n.sidebar-nav ul.app-sub-sidebar li a:hover {\n border-color: #ba9afd;\n text-decoration: none;\n color: #ba9afd;\n border-left: 4px solid #ba9afd;\n}\n\n.sidebar .search .input-wrap {\n padding: 8px 15px;\n margin: 0;\n border-radius: 50px;\n border: 2px solid #6660b9;\n}\n.sidebar .search input[type=\"search\"],\n.sidebar .search input[type=\"search\"]:focus {\n background-color: #2d1763;\n outline: none;\n box-shadow: none;\n}\n.sidebar-nav a:hover {\n text-decoration: none;\n}\n@keyframes tabFade {\n 0% {\n opacity: 0;\n }\n\n to {\n opacity: 1;\n }\n}\n/* content */\n.markdown-section img {\n border-radius: 8px;\n}\n.markdown-section h2 a::before,\n.markdown-section h3 a::before,\n.markdown-section h4 a::before,\n.markdown-section h5 a::before,\n.markdown-section h6 a::before {\n color: #ba9afd;\n margin-right: 5px;\n}\n\n.app-nav li a {\n color: #fff;\n font-weight: bold;\n}\n\n.sidebar-toggle .sidebar-toggle-button {\n padding: 20px;\n border-radius: 5px;\n --sidebar-toggle-icon-height: 8px;\n --sidebar-toggle-icon-stroke-width: 2px;\n background: #6e52a9;\n}\n\n@media only screen and (min-width: 768px) {\n .sidebar-toggle .sidebar-toggle-button {\n padding: 20px;\n border-radius: 5px;\n --sidebar-toggle-icon-height: 8px;\n --sidebar-toggle-icon-stroke-width: 5px;\n background: #6e52a9;\n }\n .sidebar-toggle span:nth-child(1) {\n transform: rotate(-45deg);\n }\n\n .sidebar-toggle span:nth-child(2) {\n display: none;\n }\n\n .sidebar-toggle span:nth-child(3) {\n transform: rotate(45deg);\n }\n\n .ready-fix.close .sidebar-toggle span:nth-child(1) {\n transform: rotate(45deg);\n }\n\n .ready-fix.close .sidebar-toggle span:nth-child(3) {\n transform: rotate(135deg);\n }\n}\n\n.sidebar-toggle span {\n transition: transform 0.5s ease-in-out;\n}\n\n.btn-primary,\n.markdown-section a.btn-primary {\n border: none;\n outline: none;\n cursor: pointer;\n text-align: center;\n border-radius: 3rem;\n background: #ba9afd;\n padding: 0.75rem 1.5rem 0.85rem;\n font-size: 1.13rem;\n font-weight: 500;\n line-height: 1;\n color: #190c39;\n margin: 10px 0;\n display: inline-block;\n text-decoration: none;\n}\n\n.btn-primary::after {\n display: inline-block;\n margin-left: 4px;\n font-size: 22px;\n content: \"➡\";\n}\nbody .pagination-item-title,\nbody .pagination-item-label {\n font-weight: bold;\n color: #fff;\n opacity: 1;\n}\n\n.app-name-link {\n display: flex;\n align-items: center; /* Vertical align */\n justify-content: center;\n font-weight: bold;\n font-size: 25px;\n}\n\n.logo {\n display: inline;\n width: 40px;\n margin-right: 5px;\n}\n\n.markdown-section table {\n overflow-x:scroll;\n width: 100%;\n display:block;\n}\n\n.sidebar-nav li,\n.sidebar-nav li * {\n white-space: normal !important;\n overflow: visible !important;\n text-overflow: clip !important; \n word-break: break-word !important;\n}" }, { "path": "docs/assets/css/editor.css", "content": "/*\n===============================================================================================================================\nCSS for better Markdown previews within a text editor.\n===============================================================================================================================\n*/\n\n.badge {\n color: #fff;\n background-color: #6c757d;\n display: inline-block;\n padding: .25em .4em .25em .4em;\n font-size: 75%;\n font-weight: 700;\n line-height: 1;\n text-align: center;\n white-space: nowrap;\n vertical-align: middle;\n margin-top: -0.4em;\n border-radius: .25rem;\n transition: color .15s ease-in-out, background-color .15s ease-in-out, border-color .15s ease-in-out, box-shadow .15s ease-in-out;\n text-decoration: none;\n}\n\n.badge a {\n color: white;\n text-decoration: none !important;\n}\n\nul {\n list-style: square outside none;\n}\n\n.alert {\n overflow: visible;\n margin: 2em 0;\n padding: 1.5em;\n background: #f7f7f7;\n}\n\n.alert ul {\n list-style: none;\n margin-top: .8em;\n}\n\n.alert ul li {\n margin: 2px 0;\n}\n\n.alert ul li:before {\n position: absolute;\n content: '\\2B29';\n margin-left: -18px;\n}\n\n.blockquote ul {\n list-style: none;\n margin-top: .8em;\n}\n\n.blockquote ul li {\n margin: 2px 0;\n}\n\n.blockquote ul li:before {\n position: absolute;\n content: '\\2B29';\n margin-left: -18px;\n}\n\n.video-container-4by3 {\n position: relative;\n padding-bottom: 75%;\n height: 0;\n overflow: hidden;\n max-width: 100%;\n}\n\n.video-container-16by9 {\n position: relative;\n padding-bottom: 56.25%;\n height: 0;\n overflow: hidden;\n max-width: 100%;\n}\n\n.video-container-16by9 iframe, .video-container-4by3 iframe, .embed-container object, .embed-container embed {\n position: absolute;\n top: 0;\n left: 0;\n width: 100%;\n height: 93%;\n}\n" }, { "path": "docs/assets/css/theme.css", "content": ".app-nav:not(:empty)~main .markdown-section {\n padding-top: 5.0rem;\n}\n\n.pagination-item, .pagination-item-title {\n opacity: .9 !important;\n}\n\n.pagination-item:not(:last-child) a .pagination-item-label, .pagination-item:not(:last-child) a .pagination-item-subtitle, .pagination-item:not(:last-child) a .pagination-item-title {\n opacity: .9 !important;\n transition: all .2s;\n}\n\n.markdown-section {\n padding: 1rem 40px;\n}\n\n.markdown-section .alert, .markdown-section blockquote {\n overflow: visible;\n margin: 1em 0;\n padding: 1em;\n border-width: var(--blockquote-border-width, 0);\n border-style: var(--blockquote-border-style);\n border-color: var(--blockquote-border-color);\n border-radius: var(--blockquote-border-radius);\n background: var(--blockquote-background);\n color: var(--blockquote-color);\n font-family: var(--blockquote-font-family);\n font-size: var(--blockquote-font-size);\n font-style: var(--blockquote-font-style);\n font-weight: var(--blockquote-font-weight);\n quotes: \"“\"\"”\"\"‘\"\"’\";\n}\n\n.markdown-section ul {\n list-style: square outside none;\n}\n\n.markdown-section .alert ul, .markdown-section blockquote ul {\n list-style: none;\n margin-top: .8em;\n}\n\n.markdown-section .alert ul li, .markdown-section blockquote ul li {\n margin: 2px 0;\n}\n\n.markdown-section .alert ul li:before, .markdown-section blockquote ul li:before {\n position: absolute;\n content: '\\2B29';\n margin-left: -18px;\n}\n\n.markdown-section .button {\n cursor: pointer;\n color: var(--base-background-color);\n height: auto;\n display: inline-block;\n margin-top: 4px;\n padding: 10px;\n font-family: -apple-system, \"Segoe UI\", \"Helvetica Neue\", sans-serif;\n line-height: 1.2rem;\n background-color: var(--link-color);\n text-decoration: none;\n border-radius: .25rem;\n}\n\n.markdown-section a.button {\n cursor: pointer;\n color: var(--base-background-color);\n text-decoration: none !important;\n}\n\n.markdown-section .button-rounded {\n cursor: pointer;\n color: var(--base-background-color);\n height: auto;\n display: inline-block;\n padding: 10px min(20px, 5%) 10px min(20px, 5%);\n font-family: -apple-system, \"Segoe UI\", \"Helvetica Neue\", sans-serif;\n line-height: 1.2rem;\n background-color: var(--link-color);\n text-decoration: none;\n border-radius: 1.2rem;\n}\n\n.markdown-section a.button-rounded {\n cursor: pointer;\n color: var(--base-background-color);\n text-decoration: none !important;\n}\n\n.markdown-section .navpill {\n cursor: pointer;\n color: var(--base-color);\n height: auto;\n display: inline-block;\n border: 1px solid var(--base-color);\n border-radius: 4rem;\n padding: 4px 14px 4px 14px;\n margin-bottom: 4px;\n margin-right: 6px;\n font-size: .8rem;\n line-height: .9rem;\n background-color: --base-background-color;\n font-family: -apple-system, \"Segoe UI\", \"Helvetica Neue\", sans-serif;\n font-weight: bold;\n text-decoration: none;\n}\n\n.markdown-section a.navpill {\n cursor: pointer;\n color: var(--base-color);\n border: 1px solid var(--base-color);\n text-decoration: none !important;\n}\n\n.markdown-section .badge {\n color: var(--base-background-color);\n background-color: color-mix(in srgb, var(--base-color) 70%, transparent);\n display: inline-block;\n padding: .25em .4em .25em .4em;\n font-family: -apple-system, \"Segoe UI\", \"Helvetica Neue\", sans-serif;\n font-size: 75%;\n font-weight: 700;\n line-height: 1;\n text-align: center;\n white-space: nowrap;\n vertical-align: middle;\n margin-top: -0.4em;\n border-radius: .25rem;\n transition: color .15s ease-in-out, background-color .15s ease-in-out, border-color .15s ease-in-out, box-shadow .15s ease-in-out;\n text-decoration: none;\n}\n\n.markdown-section .badge a {\n color: var(--base-background-color)!important;\n text-decoration: none !important;\n}\n\n.markdown-section a[href$=\"?id=a\"], .markdown-section a[href$='?id=b'], .markdown-section a[href$=\"?id=c\"], .markdown-section a[href$=\"?id=d\"], .markdown-section a[href$=\"?id=e\"], .markdown-section a[href$=\"?id=f\"], .markdown-section a[href$=\"?id=g\"], .markdown-section a[href$=\"?id=h\"], .markdown-section a[href$=\"?id=i\"], .markdown-section a[href$=\"?id=j\"], .markdown-section a[href$=\"?id=k\"], .markdown-section a[href$=\"?id=l\"], .markdown-section a[href$=\"?id=m\"], .markdown-section a[href$=\"?id=n\"], .markdown-section a[href$=\"?id=o\"], .markdown-section a[href$=\"?id=p\"], .markdown-section a[href$=\"?id=q\"], .markdown-section a[href$=\"?id=r\"], .markdown-section a[href$=\"?id=s\"], .markdown-section a[href$=\"?id=t\"], .markdown-section a[href$=\"?id=u\"], .markdown-section a[href$=\"?id=v\"], .markdown-section a[href$=\"?id=w\"], .markdown-section a[href$=\"?id=x\"], .markdown-section a[href$=\"?id=y\"], .markdown-section a[href$=\"?id=z\"] {\n display: inline-flex;\n padding-top: 0px;\n padding-right: 6px;\n padding-bottom: 0px;\n padding-left: 6px;\n line-height: 1.2em;\n}\n\n.markdown-section #a, .markdown-section #b, .markdown-section #c, .markdown-section #d, .markdown-section #e, .markdown-section #f, .markdown-section #g, .markdown-section #h, .markdown-section #i, .markdown-section #j, .markdown-section #k, .markdown-section #l, .markdown-section #m, .markdown-section #n, .markdown-section #o, .markdown-section #p, .markdown-section #q, .markdown-section #r, .markdown-section #s, .markdown-section #t, .markdown-section #u, .markdown-section #v, .markdown-section #w, .markdown-section #x, .markdown-section #y, .markdown-section #z {\n width: 2em;\n color: var(--base-background-color);\n font-weight: 700;\n margin-top: 1.00rem;\n padding-left: 0.25rem;\n background: color-mix(in srgb, var(--base-color) 70%, transparent);\n}\n\n.markdown-section .accordion {\n margin-top: 1.05rem;\n position: relative;\n display: -ms-flexbox;\n display: flex;\n -ms-flex-direction: column;\n flex-direction: column;\n min-width: 0;\n word-wrap: break-word;\n background-clip: border-box;\n border: 1px solid #CCCCCC;\n border-radius: .15rem;\n}\n\n.markdown-section details {\n padding: .75rem 1.25rem;\n margin-bottom: 0;\n border-bottom: 1px solid #CCCCCC;\n}\n\n.markdown-section summary {\n cursor: pointer;\n color: var(--link-color);\n padding: 0;\n\n h1, h2, h3 {\n margin: 0;\n display: inline-block;\n }\n}\n\n.markdown-section code {\n white-space: pre-wrap!important;\n}\n\n.markdown-section pre code {\n word-break: break-all!important;\n}\n\n.markdown-section .fa-fw {\n text-align: left;\n}\n\n.markdown-section .video-container-4by3 {\n position: relative;\n padding-bottom: 75%;\n height: 100%;\n overflow: hidden;\n max-width: 100%;\n}\n\n.markdown-section .video-container-16by9 {\n position: relative;\n padding-bottom: 56.25%;\n height: 100%;\n overflow: hidden;\n max-width: 100%;\n}\n\n.video-container-16by9 iframe, .video-container-4by3 iframe, .embed-container object, .embed-container embed {\n position: absolute;\n top: 0;\n left: 0;\n width: 100%;\n height: 100%;\n}\n\n.markdown-section .responsive-container iframe {\n max-width: 100%;\n}\n\n.markdown-section .banner-image {\n width: 100%;\n height: 125px;\n object-fit: cover;\n object-position: 50% 50%;\n}\n\n@media (min-width: 576px) {\n .markdown-section .banner-image {\n height: 250px;\n }\n}\n\n.markdown-section .banner-tall-image {\n width: 100%;\n height: 175px;\n object-fit: cover;\n object-position: 50% 50%;\n}\n\n@media (min-width: 576px) {\n .markdown-section .banner-tall-image {\n height: 350px;\n }\n}\n\n.markdown-section .header-image-fade {\n width: 100%;\n margin: 0px auto;\n position: absolute;\n top: 0px;\n left: 0;\n -webkit-mask-image: -webkit-gradient(linear, left top, left bottom, from(rgba(0,0,0,1)), to(rgba(0,0,0,0)));\n mask-image: linear-gradient(to bottom, rgba(0,0,0,1), rgba(0,0,0,0));\n opacity: 0.4;\n z-index: -1;\n}\n\n@media screen and (max-width: 980px) {\n .markdown-section .header-image-fade {\n top: -20px;\n }\n}\n\n/* CSS currently only works with sidebar and standalone pages */\n.markdown-section .header-image-full-width {\n margin-top: -2rem;\n left: 50%;\n margin-left: -50vw;\n margin-right: -50vw;\n max-width: 100vw;\n position: relative;\n right: 50%;\n width: 100vw;\n height: 30dvh;\n object-fit: cover;\n object-position: center 50%;\n}\n\n.markdown-section .header-tall-image-full-width {\n margin-top: -2rem;\n left: 50%;\n margin-left: -50vw;\n margin-right: -50vw;\n max-width: 100vw;\n position: relative;\n right: 50%;\n width: 100vw;\n height: 40dvh;\n object-fit: cover;\n object-position: center 50%;\n}\n\n.markdown-section .image-75 {\n width: 75%;\n height: auto;\n}\n\n.markdown-section .image-50 {\n width: 75%;\n height: auto;\n}\n\n.markdown-section .image-25 {\n width: 75%;\n height: auto;\n}\n\n.markdown-section .image-75-border {\n width: 75%;\n height: auto;\n border: 1px solid #dfdfdf;\n}\n\n.markdown-section .image-50-border {\n width: 75%;\n height: auto;\n border: 1px solid #dfdfdf;\n}\n\n.markdown-section .image-25-border {\n width: 75%;\n height: auto;\n border: 1px solid #dfdfdf;\n}\n\n.markdown-section .image-border {\n border: 1px solid #dfdfdf;\n}\n\n.markdown-section .image-border-rounded {\n border-radius: 0.35em;\n border: 1px solid #dfdfdf;\n}\n\n.markdown-section .column {\n float: left;\n padding-right: 1rem;\n width: 50%;\n}\n\n.markdown-section .column img {\n padding-top: .35rem;\n}\n\n.markdown-section .reverse-columns .column {\n float: right;\n}\n\n.markdown-section .row:after {\n content: \"\";\n display: table;\n clear: both;\n}\n\n@media screen and (max-width:800px) {\n .markdown-section .column {\n width: 100%;\n }\n\n .markdown-section .image-75, .markdown-section .image-50, .markdown-section .image-25, .markdown-section .image-75-border, .markdown-section .image-50-border, .markdown-section .image-25-border {\n width: 100%;\n height: auto;\n }\n}\n\n.markdown-section figure, .markdown-section p, .markdown-section ol, .markdown-section ul {\n margin: 1em 0em .5em 0em;\n}\n\n.markdown-section h1 {\n line-height: 1.75rem;\n}\n\n.markdown-section h2 {\n line-height: 1.55rem;\n}\n\n.markdown-section .h3 {\n line-height: 1.35rem;\n}\n\n.markdown-section h4 {\n line-height: 1.3rem;\n}\n\n.markdown-section h5 {\n line-height: 1.25rem;\n}\n\n.markdown-section h6 {\n line-height: 1.2rem;\n}\n\n.markdown-section .alert hr, .markdown-section blockquote hr {\n margin: 1em 0;\n}\n\n.markdown-section .alert h1, .markdown-section blockquote h1 {\n font-size: 1.5rem;\n line-height: 1.6rem;\n}\n\n.markdown-section .alert h2, .markdown-section blockquote h2 {\n font-size: 1.35rem;\n line-height: 1.45rem;\n}\n\n.markdown-section .alert h3, .markdown-section blockquote h3 {\n font-size: 1.2rem;\n line-height: 1.3rem;\n}\n\n.markdown-section .alert h4, .markdown-section blockquote h4 {\n font-size: 1.15rem;\n line-height: 1.25rem;\n}\n\n.markdown-section .alert h5, .markdown-section blockquote h5 {\n font-size: 1.1rem;\n line-height: 1.2rem;\n}\n\n.markdown-section .alert h6, .markdown-section blockquote h6 {\n font-size: 1rem;\n line-height: 1.1rem;\n}\n\nbody .app-nav {\n margin-right: -10px;\n}\n\nbody .docsify-pagination-container {\n display: flex;\n flex-wrap: wrap;\n justify-content: space-between;\n overflow: hidden;\n margin: 3em 0 1em;\n border-top: 0px solid rgba(0, 0, 0, .07);\n}\n\n.progress {\n background-color: var(--blockquote-border-color);\n}\n\n@media only screen and (max-width: 480px) {\n\n .markdown-section h1 {\n font-size: 1.45rem;\n line-height: 1.5rem;\n }\n\n .markdown-section h2 {\n font-size: 1.35rem;\n line-height: 1.4rem;\n }\n\n .markdown-section h3 {\n font-size: 1.25rem;\n line-height: 1.3rem;\n }\n\n .markdown-section h4 {\n font-size: 1.15rem;\n line-height: 1.2rem;\n }\n\n .markdown-section h5 {\n font-size: 1.1rem;\n line-height: 1.15rem;\n }\n\n .markdown-section h6 {\n font-size: 1rem;\n line-height: 1.05rem;\n }\n\n .markdown-section .alert h1, .markdown-section blockquote h1 {\n font-size: 1.3rem;\n line-height: 1.4rem;\n }\n\n .markdown-section .alert h2, .markdown-section blockquote h2 { \n font-size: 1.2rem;\n line-height: 1.3rem;\n }\n\n .markdown-section .alert h3, .markdown-section blockquote h3 {\n font-size: 1.15rem;\n line-height: 1.25rem;\n }\n\n .markdown-section .alert h4, .markdown-section blockquote h4 {\n font-size: 1.1rem;\n line-height: 1.2rem;\n }\n\n .markdown-section .alert h5, .markdown-section blockquote h5 {\n font-size: 1.05rem;\n line-height: 1.1rem;\n }\n\n .markdown-section .alert h6, .markdown-section blockquote h6 {\n font-size: 1rem;\n line-height: 1.05rem;\n }\n\n}\n\n/* Dark mode colours for use with Simple light + dark theme (uncomment to use) */\n/* @media (prefers-color-scheme: dark) { */\n/*\n :root {\n --link-color: #1BA1EE!important;\n\n --sidebar-name-color: #1BA1EE!important;\n --sidebar-nav-link-color--active: #1BA1EE!important;\n --sidebar-nav-link-border-color--active: #1BA1EE!important;\n\n --sidebar-nav-pagelink-background--active:\n no-repeat 0px center / 5px 6px\n linear-gradient(225deg, transparent 2.75px, #1BA1EE 2.75px 4.25px, transparent 4.25px),\n no-repeat 5px center / 5px 6px\n linear-gradient(135deg, transparent 2.75px, #1BA1EE 2.75px 4.25px, transparent 4.25px)!important;\n --sidebar-nav-pagelink-background--collapse:\n no-repeat 2px calc(50% - 2.5px) / 6px 5px\n linear-gradient(45deg, transparent 2.75px, #1BA1EE 2.75px 4.25px, transparent 4px),\n no-repeat 2px calc(50% + 2.5px) / 6px 5px\n linear-gradient(135deg, transparent 2.75px, #1BA1EE 2.75px 4.25px, transparent 4px)!important;\n --sidebar-nav-pagelink-background--loaded:\n no-repeat 0px center / 5px 6px\n linear-gradient(225deg, transparent 2.75px, #1BA1EE 2.75px 4.25px, transparent 4.25px),\n no-repeat 5px center / 5px 6px\n linear-gradient(135deg, transparent 2.75px, #1BA1EE 2.75px 4.25px, transparent 4.25px)!important;\n\n --navbar-root-color--active: #1BA1EE!important;\n --navbar-root-color--active: #1BA1EE!important;\n\n --blockquote-border-color: #1BA1EE!important;\n \n --pagination-title-color: #1BA1EE!important;\n }\n}\n*/\n" }, { "path": "docs/assets/css/toc.css", "content": ".content *::-webkit-scrollbar {\n background-color: transparent;\n width: 12px;\n}\n.content *::-webkit-scrollbar-track {\n background-color: transparent;\n}\n.content *::-webkit-scrollbar-thumb {\n border-radius: 20px;\n border: 3px solid transparent;\n background-color: rgba(0,0,0,0.3);\n background-clip: content-box;\n}\n.content {\n display: flex;\n flex-direction: row-reverse;\n justify-content: center;\n}\n.markdown-section {\n flex: 1 1 0%;\n margin: 0 48px;\n}\n.nav {\n width: var(--toc-width, 280px);\n min-width: 200px;\n align-self: flex-start;\n flex: 0 0 auto;\n}\naside.nav.nothing {\n width: 0;\n}\n\n.page_toc {\n border-left-style: solid;\n border-left-width: 1px;\n border-left-color: rgba(0, 0, 0, 0.07);\n border-image-slice: 1;\n padding-left: 5px;\n position: -webkit-sticky;\n position: fixed;\n overflow-y: scroll;\n max-height: 100vh;\n top: 0;\n bottom: auto;\n margin-right: 10px;\n scrollbar-width: thin !important;\n scrollbar-color: grey transparent;\n}\n\n.page_toc a > * {\n pointer-events: none;\n}\n\n.page_toc code {\n background-color: #f8f8f8;\n border-radius: 2px;\n color: #e96900;\n font-family: 'Roboto Mono', Monaco, courier, monospace;\n font-size: 0.8rem;\n margin: 0 2px;\n padding: 3px 5px;\n}\n\n.page_toc p.title {\n margin: 0px 0 0px 9px;\n padding-top: 15px;\n padding-bottom: 5px;\n font-weight: 400;\n font-size: 1.2em;\n}\n.page_toc .anchor:hover:after {\n content: \"\";\n}\n\n.page_toc ul {\n list-style-type: none;\n margin-top: 0px;\n padding-left: 10px;\n color: var(--base-color, black);\n text-decoration: none;\n font-weight: 400;\n line-height: 1.2em;\n}\n\n.page_toc ul a:hover span {\n border-bottom: none !important;\n text-decoration:underline !important;\n}\n\n.page_toc ul a {\n color: var(--base-color, black);\n text-decoration: none;\n font-weight: 400;\n line-height: 1.2em;\n}\n\n.page_toc ul li {\n padding-top: 7px;\n}\n\n@media screen and (max-width: 900px) {\n .page_toc {\n position: relative;\n top: -20px;\n padding: 10px 0;\n border: none;\n border-bottom: 1px solid #ddd;\n font-size: 1.0em;\n }\n .nav {\n margin: 0 auto;\n width: 900px;\n }\n .page_toc p.title {\n font-weight: 400;\n font-size: 1.2em;\n }\n .content {\n display: block;\n }\n .markdown-section {\n margin: 0 auto;\n }\n}\n\n/*\n.page_toc .active {\n border-left: 5px solid;\n color: var(--theme-color, #42b983);\n padding-left: 10px;\n}\n*/\n" }, { "path": "docs/assets/ics/eps25townhall.ics", "content": "BEGIN:VCALENDAR\nVERSION:2.0\nPRODID:-//ical.marudot.com//iCal Event Maker\nCALSCALE:GREGORIAN\nBEGIN:VEVENT\nDTSTAMP:20250206T151639Z\nUID:1738854242598-64367@ical.marudot.com\nDTSTART:20250212T150000Z\nDTEND:20250212T160000Z\nSUMMARY:Town Hall - Ethereum Protocol Studies\nDESCRIPTION:An information session and Q&A about the 2025 Ethereum Protocol Studies group.\nLOCATION:https://meet.ethereum.org/eps-town-hall-25\nBEGIN:VALARM\nACTION:DISPLAY\nDESCRIPTION:Town Hall - Ethereum Protocol Studies\nTRIGGER:-PT15M\nEND:VALARM\nEND:VEVENT\nEND:VCALENDAR" }, { "path": "docs/contributing.md", "content": "# Contribute to the Protocol Wiki\n\nThe Protocol Wiki is an open and collaborative project. Whether you are part of the [Study Group](/eps/intro.md) or not, we welcome your contributions! Help us to build the documentation and improve availability of learning resources on Ethereum core R&D.\n\n*We are not aiming to rewrite other existing Ethereum documentation* but rather create a cohesive collection of technical resources for aspiring core developers and researchers.\n\nWhen creating contributions, consider whether it doesn't exist in another form elsewhere. Use it and reference it in your text but do not copy its content. Focus on adding it into a big picture, connecting it with related topics. \n\nWrite contributions based on what you learned about the protocol along the way, what experience you gathered and missing pieces that slowed you down. Consider it as explaining to your peers, reflect on your own journey as a core developer/researcher.\n\n## Contributing\n\nBefore you start with editing, please read the code of conduct, following guide and make yourself familiar with the overall wiki structure. \n\nThe wiki source is hosted in Github repository at [github.com/eth-protocol-fellows/protocol-studies](https://github.com/eth-protocol-fellows/protocol-studies). Github repo is the main coordination and hosting platform but wiki source is also mirrored on [radicle](https://app.radicle.xyz/nodes/seed.radicle.garden/rad:zkV49UANVb2w2g5eE4Le197Wuasz) and [independent centralized host](https://git.ethquokkaops.io/eth-protocol-fellows/protocol-studies). \n\n> The wiki is served from `wiki-pages` branch which is regularly updated from `main`. When contributing, open a PR to a branch related to the change or `main` for smaller quick fixes. PRs from other branches are reviewed before merging to `main` and collected updates are then pushed to update the `wiki-pages`.\n\nExplore existing issues or open a new one for missing content, suggest improving existing content or wiki frontend features. If you identify missing or unfinished content, feel free to open a PR. First, check existing PRs or branches to make sure your work is not redundant. \n\nWe are not aiming to recreate other existing wikis. If the same content is well explained elsewhere, just link it and provide additional context. \n\n### What does(n't) belong here\n\nThe scope of this wiki is limited to technical resources of the Ethereum core protocol infrastructure. This means its specifications, implementations, testing, research or related tooling. \n\nIt **does not** cover onchain protocols/dapps, layer 2s/rollups or any other tools which are not dependencies of core infrastructure. In other words, stuff which would be covered by EIPs, not ERCs.\n\n### Structure and collaboration\n\nThe wiki is supposed to cover all important parts of Ethereum core protocol and its development. The protocol architecture and related topics is reflected in the wiki format. The whole wiki lives under `/docs/wiki` and the `/docs/_sidebar.md` defines the main documentation structure. \nHigh level areas are abstracted to directories which include all subtopics. Focus your contributions to wiki itself. Week pages in `eps` directory are meant for weekly presentations information, not main place for resources. \n\nFor contributors, we recommend focusing on specific topics contained in corresponding documents. It's best to own a single topic and work out all the details. Create a new document and add the topic to the sidebar if it's not there yet. Join the [discord server](https://discord.gg/8RPnPGEQtJ), let others know what you are working on in the group channel and collaborate with other contributors writing about related topics. If you are working with multiple people on a significant piece of content, you can have a dedicated branch in the repo for easier coordination. \n\n## Editing wiki\n\nThe wiki is a collection of regular markdown files which can be edited directly using github interface or your favorite markdown editor. When making commits and opening PRs, please provide a commentary explaining your contribution.\n\nThe web docs version is generated by [Docsify](https://docsify.js.org/). Learn about its [config](https://docsify.js.org/#/configuration) and [features](https://docsify.js.org/#/plugins) options. The configuration and web design is also open to improvements or suggestions. \n\nFor more extensive edits or changes to configuration, use Docsify to preview the web locally. You just need git and node.js. \n\nInstall docsify, clone the repository and host it locally. \n\n```\nnpm i docsify-cli -g\ngit clone https://github.com/eth-protocol-fellows/protocol-studies.git\ncd protocol-studies\ndocsify serve ./docs\n```\n\n## Fixing typos locally\nThe aspell typo checker is run on every PR and checks all files, it's advised to run it locally prior to submitting a pull request to resolve flagged words in your changes.\n\nTo check for typos locally:\n1. Install [aspell](https://www.gnu.org/software/aspell/) for your platform.\n2. Navigate to the project root and run the script:\n```\nbash check_typos.sh\n```\n\nTo fix the typos:\n1. Open the relevant files and fix any identified typos.\n2. Update wordlist: If a flagged word is actually a project-specific term add it to `wordlist.txt` in the project root.\n Each word should be listed on a separate line.\n * Remember:\n * When adding new words it must NOT have any spaces or special characters within or around it.\n * \\`wordlist\\` is NOT case sensitive.\n * Use backticks to quote code variables so as to not bloat the \\`wordlist\\`.\n * Use the HTML tag to surround proper names. John Doe\n\n\n## Style guide\n\nWiki pages follow standard Markdown which can be rendered by Github or Docsify. For details on using it, look into the Markdown [guide](https://www.markdownguide.org/). \n\nThe audience of this wiki is technical and the content should reflect that. There are many guides on technical and documentation writing you can learn from, for example you can check [this lecture](https://www.youtube.com/watch?v=vtIzMaLkCaM) to get started.\n\n Here are main guidelines to follow when writing this wiki:\n\n- Write in an objective, clear and explanatory tone\n- Avoid unnecessary simplifications, describe the technical reality\n- Avoid using too long and complex sentences or paragraphs\n - Use concise and clear statements \n - Break down your text using blockquotes, bullet points or images \n- Always link your resources and verify them\n- Use bullet points or tables for topics which require enumerating \n- Highlight keywords to support scanning and skimming through the article\n- Provide visualizations to explain the topic better\n- When adding pictures, add them to a directory for images and use their relative path\n- When using acronyms or a technical jargon, make sure to introduce it first \n- Ethereum is changing fast, write the content to be as much future proof as possible \n- Don't use LLMs to generate the text\n - We don't accept texts fully generated by AI, however we recommend using it to fix grammar or phrasing\n- Consider creating tutorials and hands-on guides documenting technical steps\n- Add recommended reading at the top, point to topics which are dependencies of yours\n- For mathematical notations, you can use Katex\n- You can use mermaid diagrams for visualizations\n\nGoal is to produce a credible neutral text which is formal, well-structured, and maintains a clear progression of ideas. The content should be purely technical and shouldn't waste space on introducing high level/well known concepts. Introductory topics are necessary and can use comparisons, historical anecdotes, and concrete examples to make complex concepts more accessible.\n\n\n### Content standardization\n\nThe wiki uses American English over British spelling. Terminology, capitalization and nomenclature should match across all pages. Use [Ethereum.org guide](https://ethereum.org/contributing/style-guide/content-standardization) for the reference. \n\nUsage of images and visualizations is encouraged. If you are using an image created by a third party, make sure its license allows it and provide link to the original. For creating your own visualizations, we suggest [excalidraw.com](https://github.com/excalidraw/excalidraw). \n\nFeel free to use [emojis](https://docsify.js.org/#/emoji?id=emoji) or [icons](https://icongr.am/fontawesome) where it fits, for example in blockquotes. \n\n### Linking resources\n\nWhen adding an external link, you can use it directly in the text or on the bottom of the page in \"Resources\" section.\n\nWhen linking resources use descriptive names, such as [inevitableeth.com](https://inevitableeth.com/) instead of generic phrases like [this wiki](https://inevitableeth.com/).\n\nDon't overwhelm reader with too many resources within the text.\n\nWhen linking a page within this wiki, use a relative path and if it references specific topic within the page, use a link to heading IDs. \n\nFor other important links, add a section on the bottom of the page with list of resources. Resources should have a name or short description with a link and alternative link to its archived mirror. We strongly suggest adding a link to the latest snapshot from archive.org. Example of a link in a resource section: \n\n[JSON-RPC API reference](https://ethereum.org/en/developers/docs/apis/json-rpc), [archived](https://web.archive.org/web/20240117035335/https://ethereum.org/en/developers/docs/apis/json-rpc)\n\n### In-page notices\n\nWe use blockquote notices at the top of the page to provide readers with appropriate context regarding the content of the page. \n\n#### Active research\n\nWiki pages that are subject to future updates, i.e. pages covering active research topics require a notice to be added on top of the pages:\n\n```\n* Warning message artifact using the following format:\n> [!WARNING]\n> This document covers an active area of research, may be outdated at time of reading and subject to future updates, as the design space around evolves.\n```\n\n#### Roadmap tracker\n\nTo help user navigate across research topics, we are using a roadmap tracker with the following format:\n ``` \n| Upgrade | URGE | Track | Topic | Cross-references |\n|:-------:|:-----------:|:---------:|:---------------------------------:|:-----------------------------------------------------------------------------------------:|\n| ePBS | the Scourge | MEV track | Endgame block production pipeline | intersection with: [ET](/wiki/research/ET.md), [PEPC](), [IL]() |\n```\nIdeally, references point to a local wiki pages.\n\n#### Incomplete pages\n\nPages with minimal content which need more work to cover the topic need to include a notice: \n\n```\n> :warning: This article is a [stub](https://en.wikipedia.org/wiki/Wikipedia:Stub), help the wiki by [contributing](/contributing.md) and expanding it.\n```\n\n## Anything else?\n\nThis page is also opened for contributors! Suggest improvements to our style and guidelines in the github repo. \n" }, { "path": "docs/epf.md", "content": "# Ethereum Protocol Fellowship (EPF)\n\nThe Ethereum Protocol Fellowship (EPF) is a program designed to provide developers and researchers with a \nstructured environment to contribute directly to Ethereum core protocol. The fellowship offers participants \nmentorship, learning opportunities, and hands-on experience working on some of the most pressing technical \nchallenges in Ethereum.\n\n## Why EPF?\n\nEthereum’s core protocol development is a highly specialized and rapidly evolving field. EPF helps onboard \nand support the next generation of protocol contributors by providing:\n\n- **Access to core development community** – Work alongside Ethereum’s top researchers and engineers.\n- **Real-world experience** – Contribute to open issues in Ethereum’s execution and consensus layers.\n- **Choose your project** – No fixed curriculum, just deep technical engagement.\n- **Permissionless participation** – The door is wide open.\n- **Funding support** – Some fellows receive stipends to focus on the program.\n\n## Past Cohorts & Resources\n\nEach EPF cohort has produced meaningful contributions to Ethereum’s roadmap. You can explore past work and\ndiscussions here:\n\n- [EPF5 GitHub Repository](https://github.com/eth-protocol-fellows/cohort-five)\n- [EPF4 GitHub Repository](https://github.com/eth-protocol-fellows/cohort-four)\n- [EPF3 GitHub Repository](https://github.com/eth-protocol-fellows/cohort-three)\n- [CDAP1 GitHub Repository](https://github.com/eth-protocol-fellows/cohort-one)\n- [CDAP0 GitHub Repository](https://github.com/eth-protocol-fellows/cohort-zero)\n\n## How to Get Involved\n\nThe best way to get involved is to start contributing to Ethereum’s protocol discussions and codebase. Follow these steps:\n\n1. **Join the Ethereum R&D Discord** – Engage with the community and ask questions. [Discord Invite](https://discord.gg/ethereum)\n2. **Follow Ethereum Improvement Proposals (EIPs)** – Read and discuss active proposals on [EthMagicians](https://ethereum-magicians.org/) and [ethresear.ch](https://ethresear.ch/).\n3. **Explore good first issues** – Make your first contributions via [Good First Issues](https://gfi.bordel.wtf).\n4. **Apply for the next EPF cohort** – Keep an eye out for announcements on the [Ethereum Foundation Blog](https://blog.ethereum.org).\n\nEPF isn’t just about writing code—it’s about becoming a core part of Ethereum’s long-term development. If you’re passionate about advancing Ethereum’s protocol, this is the best way to get started.\n" }, { "path": "docs/eps/archive.md", "content": "\n - **Introduction**\n - [Prepare for studies](/eps/week0.md)\n - [Protocol intro and overview](/eps/week1.md)\n - [CL intro](/eps/week3.md)\n - [EL intro](/eps/week2.md)\n - [Using clients](/eps/nodes_workshop.md)\n - [CL/EL specs](/eps/week6-dev.md)\n - [Testing and security](/eps/week4.md)\n - [Local prototyping](/eps/week9-dev.md)\n - [Research overview](/eps/week5.md)\n - **Consensus Layer**\n - [Gasper](/eps/day16.md)\n - [CL client architecture](/eps/week8-dev.md)\n - [CL Data structures](/eps/day22.md)\n - [libp2p](/eps/day19.md)\n - [Validator Client](/eps/day20.md)\n - **Execution Layer**\n - [EL client architecture](/eps/week7-dev.md)\n - [EVM](/eps/day17.md)\n - [EL Data](/eps/day23.md)\n - [devp2p](/eps/day18.md)\n - [Engine API](/eps/day21.md)\n - [EL precompiles](/eps/week10-dev.md)\n - **Research**\n - [Upcoming upgrades](/eps/day24.md)\n - [Sharding and DAS](/eps/week6-research.md)\n - [Verkle trees](/eps/week7-research.md)\n - [MEV and censorship](/eps/week8-research.md)\n - [Purge and Portal Network](/eps/week9-research.md)\n - [SSF and PoS Upgrades](/eps/week10-research.md)\n\n\n\n\nThe study group was originally run as a 10-week study program with 16 sessions in total. The original sessions are divided into 3 areas, each covering one part of the Ethereum protocol curriculum. \n\nWatch each lecture sequentially, study supplied materials and exercises. We recommend making notes and in case of any extra information, explanation needed, come to ask to Office Hours or a discord channel. \n\n## Schedule\n\nEach session is created by a core developer or researcher, comes with reading materials to get you familiar with the topic context and some also include exercises to strengthen and practice your understanding. More resources on each topic can be found in the wiki section and if they are any missing, contribute to add them. \n\nDuring first 2 weeks, participants watch previous videos and study existing materials for the given day in their own time. Every day at _3PM UTC we will hold a daily office hours running for 2 hours_ where everyone can discuss their learnings, ask questions, exchange knowledge, etc. Join at the [Office Hours call link](https://meet.ethereum.org/eps-office-hours).\n\n#### Protocol introduction\n\nThe first part of the Study Group is an introduction to the protocol, overview of its parts and development process. \n\n| Topic | Speaker |\n| --------------------------------------------------- | -------------------------------------------------------------------------------------- |\n| [Intro to EPS and Ethereum protocol](/eps/week1.md) | [Mario Havel](https://github.com/taxmeifyoucan) |\n| [Consensus layer intro](/eps/week3.md) | [Alex Stokes](https://github.com/ralexstokes) |\n| [Execution layer intro](/eps/week2.md) | [Lightclient](https://github.com/lightclient) |\n| [Using clients, nodes](/eps/nodes_workshop.md) | [Mario](https://github.com/taxmeifyoucan) |\n| [Consensus and Execution specs](/eps/week6-dev.md) | [Hsiao-Wei Wang](https://github.com/hwwhww), [Sam Wilson](https://github.com/SamWilsn) |\n| [Testing and security](/eps/week4.md) | [Mario Vega](https://github.com/marioevz) |\n| [Local prototyping](/eps/week9-dev.md) | [Parithosh](https://github.com/parithosh) |\n| [Roadmap and research overview](/eps/week5.md) | [Domothy](https://github.com/domothyb) |\n\n#### Consensus layer\n\nThe consensus layer track covers all parts of the CL, including overview of the proof-of-stake implementation, networking and data.\n\n| Topic | Speaker |\n| -------------------------------------------------- | ----------------------------------------------- |\n| [Gasper](/eps/day16.md) | [Ben Edgington](https://github.com/benjaminion) |\n| [Consensus client architecture](/eps/week8-dev.md) | [Paul Harris](https://github.com/rolfyone) |\n| [CL Data structures](/eps/day22.md) | [Michael](https://github.com/michaelsproul/) |\n| [libp2p](/eps/day19.md) | [DappLion](https://github.com/dapplion) |\n| [Validator Client](/eps/day20.md) | [James](https://github.com/james-prysm) |\n\n\n### Execution layer\n\nEvery part of the execution layer, the original Ethereum itself.\n\n| Topic | Speaker |\n| -------------------------------------------------- | ------------------------------------------------------------------------- |\n| [Execution client architecture](/eps/week7-dev.md) | [Dragan Pilipovic](https://github.com/dragan2234) |\n| [EVM](/eps/day17.md) | [Pawel Bylica](https://github.com/chfast) |\n| [EL Data](/eps/day23.md) | [Gary](https://github.com/garyschulte), [Karim](https://github.com/matkt) |\n| [devp2p](/eps/day18.md) | [Felix Lange](https://github.com/fjl) |\n| [Engine API](/eps/day21.md) | [Mikhail](https://github.com/mkalinin) |\n| [EL precompiles](/eps/week10-dev.md) | [Danno Ferrin](https://github.com/shemnon) |\n\n\n### Research\n\nThe research track provides a technical explanation of active area of research, covering major important items from most [Ethereum roadmap](https://epf.wiki/#/wiki/research/roadmap) tracks. \n\n| Topic | Speaker |\n| -------------------------------------------------- | -------------------------------------------------- |\n| [Upcoming upgrades overview](/eps/day24.md) | [Marius](https://github.com/MariusVanDerWijden) |\n| [Sharding and DAS](/eps/week6-research.md) | [Dankrad Feist](https://github.com/dankrad) |\n| [Verkle trees](/eps/week7-research.md) | [Josh Rudolf](https://github.com/jrudolf) |\n| [MEV and censorship](/eps/week8-research.md) | [Barnabe Monnot](https://github.com/barnabemonnot) |\n| [Purge and Portal Network](/eps/week9-research.md) | [Piper Merriam](https://github.com/pipermerriam) |\n| [SSF and PoS Upgrades](/eps/week10-research.md) | [Francesco D'Amato](https://github.com/fradamt) |\n\n\n### Streams and recordings\n\nTalks and calls are announced week in advance based on the schedule above. Recordings of all talks can be found on [Youtube](https://www.youtube.com/@ethprotocolfellows) or [StreamEth](https://streameth.org/archive?organization=ethereum_protocol_fellowship) archive. \n\nApart from weekly lectures, there are less regular, ad-hoc hangout calls for informal chats and calls for wiki contributors working the content. Join the Discord group to get notified about all of these events.\n" }, { "path": "docs/eps/day16.md", "content": "# Study Group Lecture 16 | Consensus and Gasper\n\nThe introductory part of the study group is now over and we are now starting the deeper dive with live sessions from core developers. \n\nFor the first session of this week, we are diving into the consensus mechanism of Ethereum with [Ben Edgington](https://x.com/benjaminion_xyz). Ben is a seasoned core contributor who worked on Teku consensus client, Optimism and is author of Eth2 Book, the annotated specification. \n\nWatch the presentation recording by [Ben Edgington](https://x.com/benjaminion_xyz) on Youtube. Slides are [available here](https://docs.google.com/presentation/d/1mSn8JUfY88HvcCauLBkKRuy3f6YFlV9VcJptav0Ef24/edit#slide=id.p). \n\n\n\n## Pre-reading\n\nBefore starting with the Day 16 content, make yourself familiar with resources in previous weeks, especially day 2 on CL and day 6 on specs (at least the CL part). You should have general understanding of Beacon Chain and different mechanism in Ethereum consensus layer. \n\nAdditionally, you can get ready by studying the following resources.\n\n- Vitalik's [Beacon Chain Fork Choice](https://github.com/ethereum/annotated-spec/blob/master/phase0/fork-choice.md) - outdated, but still excellent\n- [Consensus chapter](https://eth2book.info/latest/part2/consensus/) in the Upgrading Ethereum book\n- [Annotated spec on fork choice](https://eth2book.info/latest/part3/forkchoice/phase0/) \n\n## Outline\n\n- Introduction to Fork Choice\n- LMD GHOST\n- Casper FFG\n- Gasper\n- Q&A\n\n## Additional reading and exercises\n\n- Original Casper FFG paper: [Casper the Friendly Finality Gadget](https://arxiv.org/abs/1710.09437)\n- Gasper: [Combining GHOST and Casper (Gasper paper)](https://arxiv.org/abs/2003.03052)\n- [The blue eyes puzzle](https://xkcd.com/blue_eyes.html) - think hard! Don't give in and look up the solution too soon." }, { "path": "docs/eps/day17.md", "content": "# Study Group Lecture 17 | EVM\n\nThe introductory part of the study group is now over and we are now starting the deeper dive with live sessions from core developers.\n\nThe second session of this week is diving into Ethereum Virtual Machine (EVM) with a lecture by [Paweł Bylica](https://github.com/chfast) from Ipsilon team.\n\nWatch the lecture recording on [Youtube](https://www.youtube.com/watch?v=gYnx_YQS8cM). [Slides](https://github.com/eth-protocol-fellows/protocol-studies/blob/main/docs/eps/presentations/day17_evm.pdf).\n\n\n\n## Pre-reading\n\nBefore starting with the Day 17 content, make yourself familiar with resources in previous weeks, especially day 3 on EL and day 12 on EL client. You should have general understanding of what is EVM and different parts of execution layer.\nSome familiarity with virtual machines, assemblers or interpreters may be handy, but is not required.\n\nAdditionally, you can get ready by browsing the following concepts related to Ethereum execution:\n\n- [Transactions](https://ethereum.org/yo/developers/docs/transactions/)\n- [Accounts](https://ethereum.org/yo/developers/docs/accounts/)\n- [Ethereum Virtual Machine](https://ethereum.org/yo/developers/docs/evm/)\n- [Interactive EVM opcodes](https://www.evm.codes)\n\n## Outline\n\n- Ethereum State Transition\n- Process Virtual Machines\n- Ethereum Virtual Machine\n- Internal calls\n- Gas metering\n- Introduction to EVM Object Format (EOF)\n- Control Flow in EVM\n\n## Additional reading and exercises\n\n- [EOF - History and motivation by Danno Ferrin](https://www.youtube.com/watch?v=X2mlptWzphc)\n- [History and Future of EVM Jumps](https://www.youtube.com/watch?v=8Cp8IsmIJl4)\n" }, { "path": "docs/eps/day18.md", "content": "# Study Group Lecture 18 | EL Networking, Devp2p\n\nThe introductory part of the study group is now over and we are now starting the deeper dive with live sessions from core developers. The second week of the main phase of the study group is dedicated to networking. \n\nThe first live session this week is dedicated to execution layer networking stack, diving into devp2p. [Felix Lange](https://github.com/fjl) is a long term core developer from go-ethereum team and the maintainer of devp2p specification. \n\nhttps://www.youtube.com/watch?v=kYJ7Rj0OGv4\n\nWatch the lecture on [Youtube](https://www.youtube.com/watch?v=44-ddRK2aBc) and follow the [Devp2p spec](https://github.com/ethereum/devp2p) as demonstrated in the lecture \n\n\n\n## Pre-reading\n\nBefore starting with the Day 18 content, make yourself familiar with resources in previous weeks, especially day 3 on EL and day 7 on EL client. You should have general understanding of the execution layer and basic overview of its networking capabilities. \n\nAdditionally, you can get ready by studying the following resources.\n\n- [Devp2p spec](https://github.com/ethereum/devp2p)\n\n## Outline\n\n- EL networking\n- devp2p specs\n- ENR\n- Discv5\n- Subprotocols\n\n## Additional reading and exercises\n\n- [Demo of devp2p Wireshark Dissector](https://www.youtube.com/watch?v=AhE4KbV-f1w)\n- [devp2p development update by Felix Lange (Devcon4)](https://www.youtube.com/watch?v=N2VTqUZRxjY)\n- [Hive devp2p test simulator](https://github.com/ethereum/hive/tree/master/simulators/devp2p)" }, { "path": "docs/eps/day19.md", "content": "# Study Group Lecture 19 | CL Networking, libp2p\n\nThe introductory part of the study group is now over and we are now starting the deeper dive with live sessions from core developers. The second week of the main phase of the study group is dedicated to networking.\n\nThe second live session the week is focused on consensus layer networking which is based on libp2p. The lecture is given by [DappLion](https://github.com/dapplion), a seasoned consensus layer contributor, part SigP Lighthouse team, previously lead of Lodestar client, his main focus is currently PeerDAS.\n\nWatch the lecture on [Youtube](https://www.youtube.com/watch?v=kYJ7Rj0OGv4) and follow the [libp2p spec](https://github.com/libp2p/specs) as shown in the talk\n\n\n\n## Pre-reading\n\nBefore starting with the Day 19 content, make yourself familiar with resources in previous weeks, especially day 2 on CL and day 16 on consensus mechanism. You should have general understanding of Beacon Chain, its networking features and different mechanism in Ethereum consensus layer.\n\nAdditionally, you can get ready by studying the following resources.\n\n- [Introduction to libp2p - David Dias](https://www.youtube.com/watch?v=CRe_oDtfRLw)\n- libp2p [docs](https://docs.libp2p.io/) and [specs](https://github.com/libp2p/specs)\n\n## Outline\n\n- CL networking protocol\n- libp2p\n- Yamux\n- Noise\n- GossipSub\n\n## Additional reading and exercises\n\n- [Demystifying libp2p Gossipsub: A Scalable and Extensible p2p Gossip Protocol by Raúl Kripalani](https://www.youtube.com/watch?v=BUc4xta7Mfk)\n- [libp2p in Ethereum from block diffusion to PeerDAS and FullDAS - Csaba Kiraly](https://www.youtube.com/watch?v=sI_Qr1vHUk4)\n" }, { "path": "docs/eps/day20.md", "content": "# Study Group Lecture 20 | Validator client\n\nThe introductory part of the study group is now over and we are now starting the deeper dive with live sessions from core developers.\n\nThis lecture is focused on the validator client implementation in the consensus layer. The talk is given by [James](https://github.com/james-prysm), developer from Prysm, go implementation of Beacon Chain.\n\n[Slides](https://github.com/eth-protocol-fellows/protocol-studies/blob/main/docs/eps/presentations/day20_validator.pdf).\n\nWatch the lecture on [Youtube](https://www.youtube.com/watch?v=rgrNMbYrOmM) and follow the [slides](https://github.com/eth-protocol-fellows/protocol-studies/blob/main/docs/eps/presentations/day20_validator.pdf) and code examples from Prysm.\n\n\n\n## Pre-reading\n\nBefore starting with the Day 20 content, make yourself familiar with resources in previous weeks, especially day 2 on CL, day 6 on specs (at least the CL part) and day 16 on the consensus mechanism. You should have general understanding of Beacon Chain, different mechanism in Ethereum consensus layer and validator duties.\n\nAdditionally, you can get ready by studying the following resources.\n\n- [Annotated spec on validator incentives](https://eth2book.info/capella/part2/incentives/)\n- [The evolution of Prysm with Preston Van Loon](https://www.youtube.com/watch?v=Lvlit-nIRfM)\n- [Key manager APIs](https://ethereum.github.io/keymanager-APIs/)\n- [Remote Signer API](https://github.com/ethereum/remote-signing-api)\n- [Validator Lifecycle](https://docs.prylabs.network/docs/how-prysm-works/validator-lifecycle)\n\n## Outline\n\n- Validator Client\n- Validator Service Initialization\n- Keystore Management\n- Performing Validator Duties\n\n## Additional reading and exercises\n\n- Run a node with a validator client on Hoodi or Ephemery, follow logs to see its behavior and functions\n - [Spin up your own Ethereum validator on testnet | Devcon Bogotá](https://www.youtube.com/watch?v=dWCck2IniNc)\n- Test your validator client out on local devnet through https://github.com/ethpandaops/ethereum-package\n" }, { "path": "docs/eps/day21.md", "content": "# Study Group Lecture 21 | Engine API\n\nThis lecture dives into Engine API, the connection between consensus and execution layer. The lecture is given by [Mikhail](https://github.com/mkalinin).\n\nWatch the lecture on [Youtube](https://www.youtube.com/watch?v=rgrNMbYrOmM). [Slides are available](https://docs.google.com/presentation/d/1L2OW2_jeu7xxogFb1BjbXJZgxBzbqImU7lhLwz50o8o/edit?usp=sharing).\n\n\n\n## Pre-reading\n\nBefore starting with the Day 21 content, make yourself familiar with resources in previous weeks, especially day 2 on CL, day 3 on EL and node workshop. You should have general understanding of roles of Beacon Chain and execution layer, how they interact to create an Ethereum node and build blocks.\n\nAdditionally, you can get ready by studying the following resources.\n\n- [Engine API: Visual Guide](https://hackmd.io/@danielrachi/engine_api)\n\n## Outline\n\n- Engine API design space and history\n- EL client behavior when importing blocks\n\n## Additional reading and exercises\n\n- [Paris spec section on Engine API](https://github.com/ethereum/execution-apis/blob/main/src/engine/paris.md#routines)\n" }, { "path": "docs/eps/day22.md", "content": "# Study Group Lecture 22 | CL Data Structures\n\nThis lecture dives into data structures of the consensus layer, how Beacon state, blobs and other data is stored. The lecture is given by [Michael](https://github.com/michaelsproul/) from Lighthouse team.\n\nWatch the lecture on [Youtube](https://youtu.be/1CWqDDZauoU). [Slides are available](https://docs.google.com/presentation/d/1pp5AQ4DXmIXZ20JrI3eI9S3RyKckfhgPYqglmFXqobo/edit?usp=sharing).\n\n\n\n## Pre-reading\n\nBefore starting with the Day 22 content, make yourself familiar with resources in previous weeks, especially day 2 on CL and day 16 on Gasper. You should have general understanding of Beacon Chain, its features and different mechanism in Ethereum consensus layer.\n\nAdditionally, you can get ready by studying the following resources.\n\n- [Lighthouse tree-states ELI5 part 1](https://blog.sigmaprime.io/tree-states-part1.html)\n- [SSZ](https://epf.wiki/#/wiki/CL/SSZ)\n\n## Outline\n\n- Beacon State\n\n## Additional reading and exercises\n\n- [Lighthouse Consensus Client architecture](https://www.youtube.com/watch?v=pLHhTh_vGZ0)\n" }, { "path": "docs/eps/day23.md", "content": "# Study Group Lecture 23 | EL Data Structures\n\nThis lecture dives into data structures of the Execution layer, the Merkle Patricia Tree and how different clients implement it. The lecture is given by [Gary](https://github.com/garyschulte) and [Karim](https://github.com/matkt) from Besu team.\n\nWatch the lecture on [Youtube](https://youtu.be/EY_pVZTXS1w). [Slides are available here](https://docs.google.com/presentation/d/1YJbrZpgxjTHy7QlgXFRG5OjSK-G5uPrExBPu3Hiefvk/edit?usp=sharing).\n\n\n\n## Pre-reading\n\nBefore starting with the Day 23 content, make yourself familiar with resources in previous weeks, especially day 3 on EL and day 7 on EL client architecture.\n\nAdditionally, you can get ready by studying the following resources.\n\n- [Merkling in Ethereum](https://blog.ethereum.org/2015/11/15/merkling-in-ethereum)\n- [MPT on ethereum.org ](https://ethereum.org/en/developers/docs/data-structures-and-encoding/patricia-merkle-trie/)\n- https://en.wikipedia.org/wiki/Trie#Patricia_trees\n\n## Outline\n\n1. Overview of Ethereum State\n2. Merkle Patricia Trie (MPT)\n - The structure and the concept of a trie-within-a-trie account storage\n - What is the state root and what purpose does it serve\n - Challenges with the state size and performance over time\n3. Evolution of State Solutions: From Hash Based to Path Based\n - Describe the forest model\n - The size and performance constraints\n - Bonsai\n - path based trie\n - flat database\n - Other storage models\n - half-path, nethermind\n - erigon/reth flat db model\n - bonsai archive\n\n## Additional reading and exercises\n\n- [Bonsai Trees guide](https://consensys.io/blog/bonsai-tries-guide)\n- [Nethermind half-path](https://github.com/NethermindEth/nethermind/pull/6331)\n- [Nethermind paprika](https://github.com/NethermindEth/Paprika/blob/main/docs/design.md)\n- [Erigon schema](https://github.com/erigontech/erigon/blob/main/erigon-lib/kv/tables.go)\n- [Implementing MPT](https://medium.com/coinmonks/implementing-merkle-tree-and-patricia-trie-b8badd6d9591)\n- [Ethereum Data Structures paper](https://www.researchgate.net/publication/353863430_Ethereum_Data_Structures)\n" }, { "path": "docs/eps/day24.md", "content": "# Study Group Lecture 24 | Upcoming upgrades\n\nThe last lecture of the Study Group is looking forward to the future, covering upcoming protocol hard forks. The lecture by [Marius Van Der Wijden](https://github.com/MariusVanDerWijden) will dive into EIPs in upcoming upgrades, Pectra and Fusaka.\n\n\nWatch the lecture on [Youtube](https://youtu.be/QvZKdWZqL04do). [Slides are available here](https://docs.google.com/presentation/d/10wwANwKcdTLWwBu9NbTG6GtIEAoXQLqox6LIS03oHMo/edit?usp=sharing).\n\n\n\n## Pre-reading\n\nBefore starting with the Day 23 content, make yourself familiar with resources in previous weeks, especially day 5 on Roadmap.\n\n- https://ethereum.org/en/roadmap/pectra/\n- https://epf.wiki/#/wiki/pectra-faq\n\n## Outline\n\n- EIPs in Pectra\n- EIPs considered for Fusaka\n\n## Additional reading and exercises\n\n- https://github.com/ethereum/pm/tree/master/Pectra\n- https://github.com/ethereum/pm/tree/master/Fusaka\n- [PeerDAS in Pectra and beyond](https://www.youtube.com/watch?v=WOdpO1tH_Us)\n" }, { "path": "docs/eps/intro.md", "content": "# Ethereum Protocol Studies\n\n[Ethereum Protocol Studies group (EPS)](https://blog.ethereum.org/2025/02/05/ethereum-protocol-studies) is a community formed to gather knowledge, learn, and educate the public about the Ethereum protocol. \n\nThe protocol evolves and grows quickly, it's an always-changing infinite garden. To sustain its credible neutrality, this pace should be reflected in growing and educating the core community. Everyone using, building or living on Ethereum should be able to learn and become involved in the core protocol. The complexity of the architecture, codebases and dynamic development paired with scattered resources can discourage many talented people from participating.\n\nOriginally started in 2024, the study group is a participatory educational program that aims to improve core protocol education by introducing a curriculum focused on all parts of the Ethereum stack, building a wiki knowledge base and creating a community focused on learning about the protocol.\n\n> The Study Group is active for 2 months starting February 23rd 2026, meeting live and creating new content. Join our [community chat](https://discord.gg/8RPnPGEQtJ) and start your studies journey\n\n![Ethereum Protocol Studies](https://raw.githubusercontent.com/eth-protocol-fellows/protocol-studies/376d1fca6907d2796da0a7876703b525ef528727/docs/images/EPS2-1080.jpg)\n\n## Learn and participate \n\nThe study group content is structured into 3 modules. Introduction with high level overview of the protocol, development process and research. Then it dives deeper into each part of the protocol in consensus and execution layer. \n\n### Study Group Curriculum\n\n**The study group curriculum is available at https://study.epf.wiki**\n\nThis is a learning platform that contains interactive sessions, exercises, quizzes and more resources to get you started learning about the protocol in depth. \n\nThe original study group content that was present here is still available under [archive.md].\n\n### New Study Group Content in 2026\n\nThis year, we will be hosting 2 new modules - the cryptography of Ethereum and zkEVM/Lean Ethereum.\n\n#### Cryptography\n| Date | Session | Teacher |\n|------------|----------------------------|---------|\n| 2026-03-09 | Finite Groups & Fields | Matan Prasma |\n| 2026-03-16 | Discrete Fourier Transform | Matan Prasma |\n| 2026-03-23 | Elliptic Curves & Pairings | Matan Prasma |\n| 2026-03-30 | BLS Signatures | Matan Prasma |\n| 2026-04-07 | Proof Systems | Matan Prasma |\n\n---\n\n#### zkEVM/Lean Ethereum\n| Date | Session | Teacher |\n|------------|----------------------------|---------|\n| 2026-03-11 | Lean Consensus Overview | Emile |\n| 2026-03-24 | Lean Client Architecture | Kolby |\n| 2026-03-25 | zkEVM Fundamentals | Cody Gunton & Ignacio Hagiopan |\n| 2026-04-01 | leanSpec and tooling | O |\n| 2026-04-09 | Post-Quantum Cryptography | Justin Drake |\n\n### Program structure \n\nThe study group is an open and permissionless, and it is up to each participant as to how they want to approach it. Whether you want to learn as much as possible, focus only on certain topics or share your knowledge with others, you are welcomed. \n\n> Join our community in [Discord server](https://discord.gg/8RPnPGEQtJ). We use it for the easiest community engagement but we are aware that Discord is proprietary and doesn't respect user privacy. Consider using alternative FOSS clients like [Dissent](https://github.com/diamondburned/dissent) or [WebCord](https://github.com/SpacingBat3/WebCord). For enhancing the regular client, check [BetterDiscord](https://github.com/BetterDiscord/BetterDiscord/) project.\n\nStudy group participants collaboratively develop the [Protocol wiki](/wiki/wiki-intro.md), serving as an evolving knowledge base for current and future core developers. This can provide students with practical experience in contributing to open source resources, while gaining invaluable experience in documentation and community-driven development.\n\nWhile this program is designed to act as a precursor to the Ethereum Protocol Fellowship, the study group is for anyone that is interested in learning more about the inner workings of the Ethereum Protocol. Those that have some general knowledge or use of Ethereum and/or blockchains as well as those that have some computer science, technical, or developer experience will get the most from this program.\n\n## Important links\n\n- [Office Hours call link](https://meet.ethereum.org/eps-office-hours)\n- [Discord server](https://discord.gg/8RPnPGEQtJ)\n- [Weekly talks on StreamEth](https://streameth.org/65cf97e702e803dbd57d823f/epf_study_group)\n- [Youtube](https://www.youtube.com/@ethprotocolfellows)\n- [Sessions calendar](https://calendar.google.com/calendar/u/0?cid=Y18xY2RhMjMxNzc5NmI4NDgzZTliMjBhMGVjZTFkMDFhZWFkN2U1ZTY3N2IxNjVhOGUzZTJlMjQ3ZTQ0M2UwODhkQGdyb3VwLmNhbGVuZGFyLmdvb2dsZS5jb20) \n- [EPF mailing list](https://groups.google.com/a/ethereum.org/g/protocol-fellowship-group)\n- [EF Blog](https://blog.ethereum.org)\n\n## Calls troubleshooting\n\nFor our weekly meetings, we are using a self-hosted FOSS platform Jitsi. Even though we are doing our best, some people might experience problems during these calls, here are a few tips on troubleshooting:\n\n- Restart your browser and rejoin\n- Try a different browser (especially if you are using a Chromium based, try Firefox and vice versa)\n- Use the [mobile Jitsi app](https://jitsi.org/downloads/) instead of desktop (you just need to point it to our domain meet.ethereum.org)\n- Check your network and firewall settings, make sure your browser allows WebRTC\n- Visit Jitsi [community forum](https://community.jitsi.org/) to search for specific issue or report your problem\n\n## FAQ\n\n- **Will I learn to develop applications on the Ethereum blockchain?**\n - No. This program is not focused on Solidity or development of decentralized applications. \n- **When does it start and is the duration?**\n - The program runs from February 17 and continues for 8 weeks, concluding in April.\n- **Am I automatically accepted to EPF after attending EPFsg**\n - No. The study group is a great way to prepare for EPF, but it doesn't guarantee anything. However, EPF is a permissionless program, so you can always participate. \n- **Where is the study group located?**\n - As all core Ethereum teams, EPFsg is distributed around the globe. We will do our best to accommodate call times for the program participants.\n- **Do I need to apply and be accepted?**\n - The program is fully open, anyone can participate. We only ask you to submit a [form](https://forms.gle/G5V95qyGV8uMjKGcA) survey to let us know about your preferences, but it doesn't have any effect on your participation. \n" }, { "path": "docs/eps/nodes_workshop.md", "content": "# Study Group Lecture | Using Ethereum clients \n\nDuring Day 3, apart of [the regular presentation](https://epf.wiki/#/eps/week3), [Mario](https://twitter.com/TMIYChao) prepared a workshop to give you a hands-on experience of using Ethereum clients. We will learn how to spin up an Ethereum node by running execution and consensus client. \n\nYou can [join us for the live workshop](https://meet.ethereum.org/eps-office-hours) on Wednesday after regular Office Hours at 3PM UTC or watch the recording of the workshop from last year.\n\n[recording](https://www.youtube.com/embed/KxXowOZ2DLs?si=yLpNoczrUmxj4kE4 ':include :type=iframe width=100% height=560 frameborder=\"0\" allow=\"fullscreen\" allowfullscreen encrypted-media gyroscope picture-in-picture web-share')\n\nMake sure to prepare your environment and learn basics necessary to understand the process: \n\n## Prerequisites\n\nGet yourself familiar with Ethereum client architecture as described in Day 1 and you can check Day 2 and 3 for even better understanding of what workshop executes. The workshop will default to geth+lighthouse but if you have other preferred client to try, make yourself familiar with its documentation. \n\n- https://ethereum.org/en/developers/docs/nodes-and-clients/node-architecture/\n- https://ethereum.org/en/developers/docs/nodes-and-clients/run-a-node/\n- Client documentation of your preferred client pair \n- Basic bash/cli shell skills \n - https://btholt.github.io/complete-intro-to-linux-and-the-cli/, https://ubuntu.com/tutorials/command-line-for-beginners\n- Make yourself familiar with [Ephemery testnet](https://ephemery.dev)\n\n### Prepare your environment \n\nTo follow the workshop, make sure to prepare your environment. \n\n- Update the system and install dependencies so it doesn't block you during the workshop. \n- Install basic utils we will need like curl, git, gpg, docker\n- Install compilers for languages of clients you'd like to try to compile (we default to using prebuilt binaries)\n- The workshop environment will be a fresh Debian 12 instance but you can use any preferred distro, Mac or WSL. Process might be very similar on other unix based systems and you can always setup a VM to replicate the same environment. \n\nWe will only run a client on testnet so the hardware requirements are minimal - the goal of the workshop is not to sync the tip of the chain but only demonstrate how the node works. Default client pair will be geth+lighthouse but if there is enough time we can demonstrate switching the pair. \n\n## Outline\n\n- Introduction to running nodes\n - Choosing a client pair and environment\n- Obtaining clients \n - Downloading and verifying binary\n - Compiling a client? \n - Docker setup? \n- Client pair setup\n - Run EL+CL client on Holesky\n - Running on Ephemery using custom genesis \n - Switching CL or EL client\n - Nimbus? \n - Erigon? \n- Using the client\n - Accessing the RPC\n - http, console, wallet\n - Adding validators \n- Additional exercise if there is time\n - Systemd service\n - Monitoring node\n- Join the [Office Hours call](https://meet.ethereum.org/eps-office-hours) to follow the workshop, ask questions and get help with troubleshooting.\n\n## Additional reading and exercises \n\nThere are bunch of things we are not going to demonstrate during the workshop so you can try them yourself afterwards. \n\n- Setup monitoring with Grafana dashboard which shows detailed information on various client parameters and functions\n- Enable higher logs verbosity, read client debug logs to learn about its low level processes \n- Connect to your node using a wallet, development tooling, web3.py or JS console \n- Connect your node to the [crawler](https://www.ethernets.io/help/) and check what details it learns about it, discover new peers\n\n- https://github.com/eth-educators/ethstaker-guides/blob/main/docs/holesky-node.md\n- https://notes.ethereum.org/@launchpad/node-faq-merge\n- https://www.coincashew.com/coins/overview-eth/guide-or-how-to-setup-a-validator-on-eth2-mainnet/part-i-installation/monitoring-your-validator-with-grafana-and-prometheus\n\n\n\n\n" }, { "path": "docs/eps/presentations/week2_notes.md", "content": "# Week 2 Lecture\n\n## Overview\n\n### Block Validation\n\ngo\nfunc stf(parent types.Block, block types.Block, state state.StateDB) (state.StateDB, error) {\n if err := core.VerifyHeaders(parent, block); err != nil {\n // header error detected\n return nil, err\n }\n for , tx := range block.Transactions() {\n res, err := vm.Run(block.Header(), tx, state)\n if err != nil {\n // transaction invalid, block is invalid\n return nil, err\n }\n state = res\n }\n return state, nil\n}\n\nfunc newPayload(execPayload engine.ExecutionPayload) bool {\n if , err := stf(..); err != nil {\n return false\n }\n return true\n}\n\nhttps://github.com/ethereum/go-ethereum/blob/63aaac81007ad46b208570c17cae78b7f60931d4/consensus/beacon/consensus.go#L229C23-L229C35\n\n### Block Building\n\ngo\nfunc build(env Environment, pool txpool.Pool, state state.StateDB) (types.Block, state.StateDB, error) {\n var (\n gasUsed = 0\n txs []types.Transactions\n )\n for ; gasUsed < env.GasLimit || !pool.Empty(); {\n tx := pool.Pop()\n res, gas, err := vm.Run(env, tx, state)\n if err != nil {\n // tx invalid\n continue\n }\n gasUsed += gas\n txs = append(txs, tx)\n state = res\n }\n return core.Finalize(env, txs, state)\n}\n\n### State Transition Function\n* walkthrough go-ethereum\n\n### EVM\n\n* arithmetic\n* bitwise\n* environment\n* control flow\n* stack ops\n * push, pop, swap\n* system\n * call, create, return, sstore\n* memory\n * mload, mstore, mstore8\n\n### p2p\n\n* execution layer operates on devp2p\n* devp2p => sub-capability eth/68, eth/69, snap, whisper, les, wit\n* eth/1 -> eth/2 -> eth/6.1 -> eth/6.2 \n\n#### Responsibility\n\n* historical data\n * GetBlockHeader\n * GetBlockBodies\n * GetReceipts\n* pending transactions\n * Transactions\n * NewPooledTransactionHashes\n * GetPooledTransactions\n* state\n snap\n\n R1 -> \n / \\\n x x\n / \\ / \\ \na b c d\n\n R200 -> \n / \\\n 1 2\n / \\ / \\ \nr a c d\n\n^^^ contiguous state retrieval\n\nR200\n\na b c d\n\n\n\"healing phase\"\n\n* get R200 -> (1, 2)\n* get 1 -> (r, a)\n\nr a c d\n\n* get 2 -> (c, d)\n\n\"healing done\"\n\n\n#### Start snap\n\n* start weak subjectivity-checkpoint -> block hash\n* get block associated with hash\n* start snap against block's state\n" }, { "path": "docs/eps/week0.md", "content": "# Study Group Week 0\n\nWeek 0 marks all the time before the program begins. Use this time to prepare yourself and get a head start. \n\nFirst, please check out the [announcement blog post](https://blog.ethereum.org/2025/02/05/ethereum-protocol-studies) and fill the [initial survey](https://forms.gle/BVQZDYoV6siALtHs7).\n\n## Town Hall\n\nThe call discussed the program details, schedule and answered your questions. Recording can be found at https://www.youtube.com/watch?v=7L1270CWjXw\n\n[recording](https://www.youtube.com/embed/7L1270CWjXw?si=fVXN913ZOJytR8Rv ':include :type=iframe width=100% height=560 frameborder=\"0\" allow=\"fullscreen\" allowfullscreen encrypted-media gyroscope picture-in-picture web-share')\n\n## Pre-reading\n\nBefore the program, you should be familiar with some general concepts from Ethereum and computer science. If you are not familiar with basics of using Ethereum or have non experience with software development, we recommend gaining at least some understanding of following:\n\n- Cryptography\n - Hashing\n - Public key cryptography\n- Data structures\n - Merkle trees\n- Networking, p2p and distributed systems\n- Software development basics\n - Programming languages, compilers\n- Ethereum as a platform\n - From a user perspective\n - As a dapp developer\n\nThese are just general suggestions of domain knowledge you will need. More introductory learning resources can be found in [week 1](/eps/week1.md).\n\n### Helpful resources to get you started\n\n- [Intro to Cryptography](https://summerofprotocols.com/wp-content/uploads/2023/12/53-BEIKO-001-2023-12-13.pdf)\n- [Introduction to Modern Cryptography](https://www.cs.umd.edu/~jkatz/imc.html)\n- [Merkle trees](https://youtu.be/V6gLY-1G4Mc?si=W1ncsNYUSHjm5U4y), [in Bitcoin](https://www.youtube.com/watch?v=bBC-nXj3Ng4)\n- [Networking & p2p](https://youtu.be/ie-qRQIQT4I?si=eYKzMbn7PGk-Il9M), [in Bittorrent](https://www.youtube.com/watch?v=xH00ikD1oDo)\n" }, { "path": "docs/eps/week1.md", "content": "# Study Group Lecture 1 | Protocol Intro\n\nThe first day of the study group is dedicated to a general introduction to the protocol and R&D ecosystem.\n\n## Recording\n\nWatch **Ethereum Protocol 101** talk by Mario Havel [on StreamEth](https://streameth.org/watch?event=&session=65d77e4f437a5c85775fef9d). [Slides](https://github.com/eth-protocol-fellows/protocol-studies/tree/main/docs/eps/presentations/week1_protocol_intro.pdf)\n\n[recording](https://streameth.org/embed/?playbackId=9bc1ekw2jk5sz6c7&vod=true&streamId=&playerName=Intro+to+Ethereum+%7C+Mario+Havel+%7C+Week+1 ':include :type=iframe width=100% height=520 frameborder=\"0\" allow=\"fullscreen\" allowfullscreen')\n\nFor archive of the discussion during the talk, check the corresponding thread in `#study-group` channel of [Discord server](https://discord.gg/epfsg).\n\n## Pre-reading\n\nThis is an introductory talk which doesn't assume a lot of prior knowledge. Check some general requirements in [week 0](/eps/week0.md). Here are few more introductory materials to get you started:\n\n- [Inevitable Ethereum - World Computer](https://inevitableeth.com/home/ethereum/world-computer)\n- [Ethereum in 30 minutes](https://www.youtube.com/watch?v=UihMqcj-cqc)\n- [Ethereum.org docs](https://ethereum.org/en/what-is-ethereum/)\n\nCheck out resources within the following text and additional reading. All resources will be explained in the week 1 presentation.\n\n## Prehistory and Philosophy\n\nTo understand Ethereum design, we need to learn about predecessors and the culture it builds upon. The modern cryptocurrency ecosystem stands on decades of work by computer scientists, cryptographers and activists.\n\nStarting all the way back in the 1960s, UNIX is an operating system and philosophy that redefined the entire paradigm of computation. This is the paradigm we have been using for over 50 years and has never really changed. Its fundamental concept of modularity is important to Ethereum design and open collaborative environment of Bell Labs is similar to Ethereum core development today.\n\n> Check this documentary with Dennis Ritchie and Ken Thompson, which perfectly captures spirit and ideas behind UNIX: https://www.youtube.com/watch?v=tc4ROCJYbm0\n\nThe Free Software movement is fundamental to Ethereum and all cryptocurrencies. The open, independent and collaborative development culture of Ethereum is strongly rooted in FOSS (Free and Open Source Software). Ethereum needs to be transparently implemented in software that gives full freedom to its users. Using any FOSS can empower every user and developer, but it's necessary for security, neutrality and trustless nature of Ethereum.\n\n> To understand its importance, watch this talk by Richard Stallman, the founder of Free Software and GNU project:\n>\n> - https://www.youtube.com/watch?v=Ag1AKIl_2GM\n> - More reading: https://www.gnu.org/philosophy/free-sw.html, _The Cathedral and the Bazaar_ book: http://www.catb.org/~esr/writings/cathedral-bazaar/\n\nThe invention of [asymmetric cryptography](https://www-ee.stanford.edu/~hellman/publications/24.pdf) marks the birth of a new paradigm for cryptography applications. Later, the rise of cryptography in computation for general public enabled everyone to utilize tools for digital privacy, secure communication and fundamentally transformed cybersecurity. While nation states did not have a framework for these new concepts, [Crypto Wars](https://en.wikipedia.org/wiki/Crypto_Wars) resulted in activist movements advocating and building cryptography tools. Ultimately, these were people inventing tools and ideas which became fundamental building blocks of modern cryptocurrencies.\n\n> Get inspiration from early Cypherpunks who envisioned an independent digital realm built on trustless and borderless technologies:\n>\n> - https://activism.net/cypherpunk/manifesto.html\n> - https://activism.net/cypherpunk/crypto-anarchy.html\n> - https://www.eff.org/cyberspace-independence\n\n[Read more in the EPF wiki page on Prehistory of Ethereum.](https://epf.wiki/#/wiki/protocol/prehistory)\n\n## Ethereum Protocol Design\n\nThe actual prehistory of the protocol, early ideas and inspiration for technical decisions in Ethereum are well documented in [V's blog](https://vitalik.eth.limo/general/2017/09/14/prehistory.html).\n\nOriginally outlined in its [Whitepaper](https://ethereum.org/whitepaper#ethereum-whitepaper), Ethereum draws inspiration from Bitcoin and its background (explained above) to create a general blockchain based computation platform. The design was technically specified in [Yellowpaper](https://ethereum.github.io/yellowpaper/paper.pdf) and evolved over time. Changes are tracked in the community process of [EIPs](https://eips.ethereum.org) and current specification is implemented in Python as:\n\n- [Execution specs](https://github.com/ethereum/execution-specs)\n- [Consensus specs](https://github.com/ethereum/consensus-specs)\n\nThe specification is purely technical and doesn't provide any context or explanation for the reader. For learning about the consensus, check the annotated version [by Ben](https://eth2book.info/capella/annotated-spec/) and [by V](https://github.com/ethereum/annotated-spec).\n\nThe protocol changes over time, with each network upgrade bringing new improvements. Despite its constant changes, the architecture evolution reflects certain fundamental principles. These can be summarized as follows:\n\n- Simplicity, Universality, Modularity, Non-discrimination, Agility\n\nThese core tenets have always led the Ethereum development and should be considered with every decision on design change. In addition to this, it manages growing complexity by encapsulating it and/or sandwiching it. The current network architecture is the result of many iterations of [network upgrade history](https://ethereum.org/history).\n\n> Read more about Ethereum design principles in [the archive](https://web.archive.org/web/20220815014507mp_/https://ethereumbuilders.gitbooks.io/guide/content/en/design_philosophy.html) and also in [this wiki](/wiki/protocol/design-rationale.md)\n\nThe Ethereum network leverages decentralization to become permissionless, credibly neutral, and censorship resistant. It continues evolving to address the latest research, news, and always-present challenges. To maintain security and decentralization, blockchain technology has certain limits, mainly its scalability. Because Ethereum needs to always adhere to its principles, it motivates us to find clever solutions for these problems rather than accepting trade-offs.\n\nThe current research and development is summarized by the [roadmap](https://twitter.com/VitalikButerin/status/1741190491578810445/photo/1) overview, however cannot be fully accurate. There is no single path for Ethereum R&D, the [roadmap](https://ethroadmap.com/) only sums up its current landscape. The core ecosystem is an always growing [infinite garden](https://ethereum.foundation/infinitegarden). However, with more and more progress, Ethereum might slowly approach its ossification.\n\n> Simplified overview of the current Ethereum design can be found documentation on [node architecture](https://ethereum.org/developers/docs/nodes-and-clients/node-architecture) and in the week 1 presentation\n\nAs hinted above, the main high level components of Ethereum are execution and consensus layer. These are 2 networks which are connected and dependent on each other. Execution layer provides the execution engine, handles user transaction and all state (address, contract data) while consensus implements the proof-of-stake mechanism ensuring security and [fault tolerance](https://inevitableeth.com/home/concepts/bft).\n\n## Implementations and Development\n\nEverything mentioned above - the ideas, design and specifications comes down to the actual application here, in its implementation. An implementation of the execution layer (EL) or consensus layer (CL) is called a _client_. A computer running this client and connecting to the network is called a _node_. A node is therefore a pair of EL and CL clients actively participating in the network.\n\nSince Ethereum is formally specified, it can be implemented in different ways in any language. This results in a variety of implementations throughout the years with some already deprecated and some just being developed. The current list of production ready implementations can be found in the [docs on Nodes and clients](https://ethereum.org/en/developers/docs/nodes-and-clients#execution-clients) and week 1 presentation.\n\n> This strategy is called [client diversity](https://ethereum.org/developers/docs/nodes-and-clients/client-diversity). Ethereum does not rely on a single 'official' implementation but users can choose any client and be sure it does the job. If an issue occurs within a single client implementation, it doesn't affect the rest of the network.\n\n### Testing\n\nWith regular changes and multiple client implementations, testing is fundamental to the network security. There are a variety of testing tools and scenarios which are all heavily utilized before any network upgrade.\n\nTests are generated based on specifications and create various scenarios. Some are testing clients individually, some are simulating a testnet with all client pairs. There are different testing tools used for different parts of development cycles and parts of clients. This includes state transition testing, fuzzing, shadow forks, RPC tests, client unit tests and CI/CD, etc.\n\n> Here is a short list of repositories dedicated to testing:\n>\n> - https://github.com/ethereum/tests\n> - https://github.com/ethereum/retesteth\n> - https://github.com/ethereum/execution-spec-tests\n> - https://github.com/ethereum/hive\n> - https://github.com/kurtosis-tech/kurtosis\n> - https://github.com/MariusVanDerWijden/FuzzyVM\n> - https://github.com/lightclient/rpctestgen\n\n### Coordination\n\nThe Ethereum development is very different to a traditional, corporate kind of, projects. First of all, it's all open and public, anybody can review it or contribute. And second, there are many different teams working on different parts. All together, there are around 20 different teams from various organizations working on Ethereum.\n\nUnlike in proprietary tech, Ethereum developers are not competing but rather working together. With the complexity always growing, there are basically no people who would be experts in all of Ethereum. Instead, people develop expertise in specific domains and collaborate with others. This is possible thanks to the modularity of Ethereum and allows developers to focus on challenges they personally prefer.\n\n> The traditional development cycle for new features or changes is `Idea - Research - Development - Testing - Adoption`. However, problems might arise at any moment of this cycle resulting in iterating again from the beginning.\n\nTo be able to ship network upgrades and agree on the current development focus, there needs to be a certain coordination. All of it is also public and can be followed by anyone interested in learning about the core protocol. The coordination mainly happens via regular calls which are scheduled in the [PM repo](https://github.com/ethereum/pm). There are different kinds of developer calls with the biggest one being All Core Devs (ACD). This is where representatives of all involved teams come to discuss the current development of the consensus or execution layer.\n\nThe ideas and proposed changes from the community are coordinated using [EIP process](https://eips.ethereum.org/EIPS/eip-1). Additionally, there are a few discussion forums. The biggest one discussing core upgrades is https://ethresear.ch. Another forum which is connected to the EIP process and serves for discussion about specific proposals is [Ethereum Magicians](https://ethereum-magicians.org/).\nLots of important discussion is also happening on the R&D Discord server (ping us in EPFsg discord to get an invite) and in client team groups. There are also offsites or workshops where many core developers meet in person to speed up the process face to face.\n\n## Additional reading and exercises\n\nTo test your knowledge about the very basics of Ethereum, try a quiz:\nhttps://ethereum.org/quizzes\n\nLearn more about the roadmap:\nhttps://ethereum.org/roadmap\n\nTo explore various parts of the Ethereum protocol, check out what people have been working on within EPF:\nhttps://github.com/eth-protocol-fellows/cohort-three/tree/master/projects\nhttps://github.com/eth-protocol-fellows/cohort-four/tree/master/projects\n\n[Devcon archive](https://archive.devcon.org/archive/) is full of incredible talks diving into various technical and non-technical aspects of Ethereum.\n\nA [retrospective document](https://notes.ethereum.org/@mikeneuder/rcr2vmsvftv) on recent roadmap by Alex and Mike comes with great insights into Ethereum development, values and goals.\n\nRead more about history of Unix and Bell Labs:\nhttps://www.theregister.com/2024/02/16/what_is_unix/\nhttps://www.deusinmachina.net/p/history-of-unix\n\nFew more books I recommend:\n\nIf you are interested in early days of Ethereum, the story of its founders and creation, check out book [The Infinite Machine](https://www.camirusso.com/book). Another similar one is [Out of the Ether](https://www.goodreads.com/book/show/55360267-out-of-the-ether). (ping me for epubs)\n\nA very recent publication providing a comprehensive insight is [Absolute Essentials of Ethereum](https://www.routledge.com/Absolute-Essentials-of-Ethereum/Dylan-Ennis/p/book/9781032334189). It covers a [variety of topics](https://www.coindesk.com/consensus-magazine/2024/02/07/absolute-essentials-of-ethereum-by-paul-dylan-ennis-an-excerpt/) and I can strongly recommend it.\n\n[Mastering Ethereum](https://github.com/ethereumbook/ethereumbook) is one of the great blockchain books by aantop covering everything from basics to technical details. It's few years old and already outdated but still can be a good inspiration.\n" }, { "path": "docs/eps/week10-dev.md", "content": "# Study Group Day 10 | Precompiles \n\nDay 10 dev talk is diving into EVM precompiles and their integration in execution clients.\n\nWatch the presentation by [Danno Ferrin](https://twitter.com/shemnon), on [StreamEth](https://streameth.org/65cf97e702e803dbd57d823f/epf_study_group) and [Youtube](https://www.youtube.com/watch?v=daiMhkt0XTw)\n\n- [Presentation from the talk.](https://hackmd.io/@shemnon/precompiles)\n- [Discussion thread on Discord: Week 10D: Precompiles](https://discord.com/channels/1205546645496795137/1231990093506678785).\n\n\n\n## Pre-reading\n\nBefore starting with the week 10 development content, make yourself familiar with resources in previous weeks, especially Day 2 on EL and Day 7 on EL client. You should have understanding of the execution client architecture and EVM. \n\nThe talk will use examples from Besu, a Java implementation of execution client. At least a basic understanding of Java syntax is recommended.\n\nAdditionally, you can get ready by studying the following resources:\n- [Exploring Precompiled Contracts on Ethereum: A Deep Dive](https://lucasmartincalderon.medium.com/exploring-precompiled-contracts-on-ethereum-a-deep-dive-4e9f9682e0aa)\n- [Precompiles documentation by evm.codes](https://www.evm.codes/precompiled)\n\n## Outline\n\n- EVM Precompiles\n- How they are integrated\n- Which precompiles exist \n- How L2s and L1s use them\n- Challenges of creating precompiles\n\n## Additional reading and exercises\n\n- [EVM Precompiled and System Contract Catalog](https://github.com/shemnon/precompiles/)\n- [RollCall breakout on precompiles](https://www.youtube.com/watch?v=tg01COfxi_M)\n- [Custom RPCs and Precompiles for Hyperledger Besu](https://www.youtube.com/watch?v=djL5nczlYFw)\n" }, { "path": "docs/eps/week10-research.md", "content": "# Study Group Lecture 15 | The Ethereum fork-choice\n\nLast talk of the original study group covers a variety of topics related to the fork-choice of Ethereum, its evolution and its role in future upgrades.\n\nWatch the presentation by [Francesco](https://twitter.com/fradamt) on [StreamEth](https://streameth.org/65cf97e702e803dbd57d823f/epf_study_group) or [Youtube](https://www.youtube.com/watch?v=x-_2gAVFlw8). Presentation is [available here](https://github.com/eth-protocol-fellows/protocol-studies/blob/main/docs/eps/presentations/week10-research.pdf).\n\n\n\n## Pre-reading\n\nBefore starting with the Day 15 content, make yourself familiar with resources in previous weeks, especially day 2 on CL and day 5 on roadmap. You should have understanding of Beacon Chain and current consensus research topics.\n\nAdditionally, you can get ready by studying the following resources.\n\n- All in one resource: [PoS evolution](https://github.com/ethereum/pos-evolution/blob/master/pos-evolution.md)\n- Gasper: [Combining GHOST and Casper (Gasper paper)](https://arxiv.org/abs/2003.03052)\n- Problems with Gasper:\n - [Three attacks on PoS Ethereum](https://eprint.iacr.org/2021/1413)\n - [View-merge](https://ethresear.ch/t/view-merge-as-a-replacement-for-proposer-boost/13739)\n- Improving Gasper with Single Slot Finality:\n - [Path towards Single Slot Finality](https://notes.ethereum.org/@vbuterin/single_slot_finality)\n - [A simple single slot finality](https://ethresear.ch/t/a-simple-single-slot-finality-protocol/14920)\n\n## Outline\n\n- Gasper recap\n- Problems with Gasper and fixes\n- Single Slot Finality (SSF)\n- How fork-choice affects other Ethereum upgrades: PeerDAS and ePBS case studies\n\n## Additional reading and exercises\n\n- [Notes on SSF, Lincoln Murr](https://publish.obsidian.md/single-slot-finality/Welcome+to+My+Research!)\n- [Increase the MAX_EFFECTIVE_BALANCE – a modest proposal](https://ethresear.ch/t/increase-the-max-effective-balance-a-modest-proposal/15801)\n- [Reorg resilience and security in post-SSF LMD-GHOST](https://ethresear.ch/t/reorg-resilience-and-security-in-post-ssf-lmd-ghost/14164/3)\n" }, { "path": "docs/eps/week2.md", "content": "# Study Group Lecture 3 | Execution Layer\n\nDuring the third day, we will dive into the Execution layer of Ethereum. \n\nWatch the presentation diving into EL internals with Lightclient on [StreamEth](https://streameth.org/watch?event=&session=65dcdef0a6d370a1ab326de1) or [Youtube](https://www.youtube.com/watch?v=pniTkWo70OY). \n\nThe overview document created in the presentation is [available here](https://github.com/eth-protocol-fellows/protocol-studies/blob/main/docs/eps/presentations/week2_notes.md?plain=1).\n\n[recording](https://streameth.org/embed/?playbackId=70f6rq6un48dy74q&vod=true&streamId=&playerName=Execution+Layer+Overview+%7C+lightclient+%7C+Week+2 ':include :type=iframe width=100% height=520 frameborder=\"0\" allow=\"fullscreen\" allowfullscreen')\n\nFor written summary of week 2 presentation, check the [notes](https://ab9jvcjkej.feishu.cn/docx/BRDdd8kP9o00a2x6F4scRo0fnJh)\n\nFor archive of the discussion during the talk, check [this thread](https://discord.com/channels/1205546645496795137/1210292746817110027/1210292751158222848) in our [Discord server](https://discord.gg/epfsg). \n\n## Pre-reading\n\nBefore starting with week 2 content, make yourself familiar with resources in [week 1](/eps/week1.md). \n\nAdditionally, you should read through the following documents to prepare for the presentation:\n* [Nodes and clients](https://ethereum.org/developers/docs/nodes-and-clients)\n* [Ethereum: mechanics](https://cs251.stanford.edu/lectures/lecture7.pdf) (a lecture based on these slides is also available on YouTube: [An Overview of the Ethereum Execution Layer - Dan Boneh](https://www.youtube.com/watch?v=7sxBjSfmROc))\n\n## Outline\n\n### Overview of the execution layer node\n* Block validation\n * in overly simplistic terms, ELs process the state transition\n * each transaction is validated by the client, executed, and its result accumulated into the state trie\n * there are additional mechanisms which also must be updated each block, such as the EIP-1559 base fee, the EIP-4844 excess blob gas, the EIP-4844 beacon root ring buffer, beacon chain withdrawals, etc.\n * new nodes must also be able to join the network without too much friction, so ELs provide efficient syncing mechanism to bootstrap others\n* Block building\n * ELs also build blocks based on transactions they see around the network\n * this requires a tx pool system over p2p\n\n### State transition function\n* header validation\n * verify merkle roots\n * verify gas limit\n * verify timestamp\n* block validation\n * walkthrough [`Process(..)`](https://github.com/ethereum/go-ethereum/blob/master/core/state_processor.go#L60) in `state_processor.go`\n\n### EVM high-level\n* stack machine intro\n* look at simple programs\n* review different classes of opcodes: stack/mem manipulators, env getters, ethereum system operations, etc.\n\n### p2p high-level\n* p2p serves three main things\n * historical data\n * pending txs\n * state\n* discuss snap sync\n * phase 1: downloading snap tiles\n * phase 2: healing\n\n### JSON-RPC\n* the \"interface\" to ethereum\n * the vision is that all clients provide the exact same API and users can run any client they choose and have perfect integration with all tooling\n * not quite there, but we are fairly close\n* review main RPC methods\n\n## Additional reading and exercises \n\n- https://www.evm.codes/\n- https://ethervm.io/\n- https://github.com/ethereum/go-ethereum\n- https://github.com/ethereum/consensus-specs\n- https://github.com/ethereum/execution-specs\n- https://github.com/ethereum/devp2p\n- https://github.com/ethereum/execution-apis\n- https://blog.ethereum.org/2022/01/24/the-great-eth2-renaming\n- https://blog.ethereum.org/2021/11/29/how-the-merge-impacts-app-layer\n- [Engine API: A Visual Guide](https://hackmd.io/@danielrachi/engine_api) by [Daniel Ramirez](https://hackmd.io/@danielrachi)\n- [Understanding Ethereum by studying its source code](https://gisli.hamstur.is/2020/08/understanding-ethereum-by-studying-the-source-code/)\n\nLightclient's vim and shell setup https://github.com/lightclient/dotfiles" }, { "path": "docs/eps/week3.md", "content": "# Study Group Lecture 2 | Consensus Layer\n\nThe second day of EPFsg dives into the Consensus layer of Ethereum.\n\nWatch the presentation on overview of the CL with Alex Stokes on [StreamEth](https://streameth.org/watch?event=&session=65e9f54579935301489a01eb) or [Youtube](https://www.youtube.com/watch?v=FqKjWYt6yWk). Presentations slides are [available here](https://github.com/eth-protocol-fellows/protocol-studies/tree/main/docs/eps/presentations/week3_presentation.pdf).\n\n[recording](https://streameth.org/embed/?playbackId=66a30awapcuiok0z&vod=true&streamId=&playerName=Consensus+Layer+Overview+%7C+Alex+Stokes+%7C+Week+3 ':include :type=iframe width=100% height=520 frameborder=\"0\" allow=\"fullscreen\" allowfullscreen')\n\nFor written summary of week 3 presentation, check the [notes](https://github.com/eth-protocol-fellows/protocol-studies/files/14850973/Week.3.EPFsg.Consensus.Layer.Overview.pdf)\n\nFor archive of the discussion during the talk, check [this thread](https://discord.com/channels/1205546645496795137/1214219045205835776/1214219052969492541) in our Discord server.\n\n## Pre-reading\n\nBefore starting with the week 3 content, make yourself familiar with resources in [week 2](/eps/week2.md).\n\nAdditionally, you can read and get ready by studying the following resources:\n\n- [Ethereum.org docs on Proof-of-stake](https://ethereum.org/developers/docs/consensus-mechanisms/pos) and its subtopics\n- [Beacon Chain explainer](https://ethos.dev/beacon-chain)\n- [PoS and Solar Punk Future, Danny Ryan 2022](https://www.youtube.com/watch?v=8N10a1EBhBc), a talk before the Merge, great insight into the Merge and Beacon Chain development and testing\n\n## Outline\n\n- Blockchain enables creating a digital scarcity but it needs security which ensures its integrity\n- Distributed networks deal with Byzantine fault tolerance (BFT)\n- Bitcoin first solved the BFT with PoW\n- Ethereum moves to proof-of-stake, switching from exogenous signal for Sybil protection to endogenous in the system\n- Uses BFT majority to determine the state of the chain\n - Byzantine faults can be observed by the protocol and stake can be `slashed`\n - The fork choice rule summarized in LMD-GHOST\n - It ensures liveness thanks to Casper\n- Provides more cryptoeconomic security\n\n## Additional reading and exercises\n\n- [Gasper paper](https://arxiv.org/pdf/2003.03052.pdf)\n- [Bitwise LMD GHOST: An efficient CBC Casper fork choice rule](https://medium.com/@aditya.asgaonkar/bitwise-lmd-ghost-an-efficient-cbc-casper-fork-choice-rule-6db924e57d1f)\n- [Eth2book, annotated spec](https://eth2book.info/)\n- [Stuff you should know about PoS by Domothy](https://web.archive.org/web/20240803111840/https://domothy.com/proof-of-stake/)\n- [Slashing scenario explanation by Dankrad Feist](https://dankradfeist.de/ethereum/2022/03/24/run-the-majority-client-at-your-own-peril.html)\n- [Beacon Chain design mistakes by Justin Drake](https://www.youtube.com/watch?v=10Ym34y3Eoo)\n- [Casper and Consensus from Devcon 3](https://www.youtube.com/watch?v=2r2k6awEJr8)\n- [Anatomy of a slot](https://www.youtube.com/watch?v=EswDO0kL_O0)\n\nAfter learning about both EL and CL, run a client pair. Spin a pair of one execution and consensus client, read their logs to learn how they operate.\n" }, { "path": "docs/eps/week4.md", "content": "# Study Group Lecture 4 | Testing and Security\n\nLecture 4 is diving into the testing tools and practices necessary to keep the network secure. \n\nWatch the presentation on Ethereum core testing infrastructure on [Youtube](https://www.youtube.com/watch?v=PQVW5dJ8J0c). Presentations slides are [available here](https://github.com/eth-protocol-fellows/protocol-studies/tree/main/docs/eps/presentations/week4.pdf). \n\n[recording](https://www.youtube.com/embed/PQVW5dJ8J0c?si=fv5ww4_6zInGXpjO ':include :type=iframe width=100% height=560 frameborder=\"0\" allow=\"fullscreen\" allowfullscreen encrypted-media gyroscope picture-in-picture web-share')\n\nFor written summary of lecture 4 presentation, check the [notes](https://github.com/eth-protocol-fellows/protocol-studies/files/14850974/Week.4.EPFsg.Test.Security.Overview.pdf)\n\nFor archive of the discussion during the talk, check [this thread](https://discord.com/channels/1205546645496795137/1216771776810455160/1216771782040621118) in our Discord server.\n\n## Pre-reading\n\nBefore starting with the lecture 4 content, make yourself familiar with resources in [lecture 3](/eps/week3.md) and before. \n\nAdditionally, you can read and get ready by studying the following resources:\n\n- https://ethereum-tests.readthedocs.io/en/latest/\n- https://ethereum.github.io/execution-spec-tests\n\n## Outline\n\n- https://github.com/ethereum/execution-spec-tests\n- https://github.com/ethereum/hive\n- https://github.com/ethereum/tests\n- https://github.com/ethereum/retesteth\n- https://github.com/lightclient/rpctestgen\n- https://github.com/marioevz/eth_tools\n- https://github.com/kurtosis-tech/kurtosis\n- https://github.com/MariusVanDerWijden/FuzzyVM\n- https://github.com/MariusVanDerWijden/tx-fuzz\n\n## Additional reading and exercises \n\n- [Quest for the Best Tests, a Retrospective on #TestingTheMerge by Pari](https://archive.devcon.org/archive/watch/6/quest-for-the-best-tests-a-retrospective-on-testingthemerge/?tab=YouTube)\n- [Killing ETH - Finding Consensus Issues on Layer 1 by Marius](https://archive.devcon.org/archive/watch/6/killing-eth-finding-consensus-issues-on-layer-1/?tab=YouTube)\n- [Dencun testing](https://www.youtube.com/watch?v=88tZticGbTo)\n" }, { "path": "docs/eps/week5.md", "content": "# Study Group Lecture 5 | Research and Roadmap\n\nLecture 5 provided an overview of current research ecosystem and updated roadmap.\n\nWatch the presentation by [Domothy](https://twitter.com/domothy) on StreamEth or Youtube. Slides are [available here](https://github.com/eth-protocol-fellows/protocol-studies/blob/main/docs/eps/presentations/week5.pdf). \n\n[recording](https://www.youtube.com/embed/UClaoL12W00?si=F-H6YMD7hgjjP2AM ':include :type=iframe width=100% height=560 frameborder=\"0\" allow=\"fullscreen\" allowfullscreen encrypted-media gyroscope picture-in-picture web-share')\n\n## Pre-reading\n\nBefore starting with the lecture 5 content, make yourself familiar with resources in previous weeks. \n\nAdditionally, you can read and get ready by studying the following resources:\n\n- https://ethereum.org/en/roadmap/\n- https://domothy.com/roadmap/\n- https://members.delphidigital.io/reports/the-hitchhikers-guide-to-ethereum\n- https://ethereum.org/en/community/research/#active-areas-of-ethereum-research\n- https://domothy.com/blobspace/\n- https://vitalik.eth.limo/general/2021/12/06/endgame.html\n\n## Outline\n\n- Merge\n - Altair / light client protocol\n - Merge / Withdrawals\n - Single Slot Finality\n - Secret Leader Election\n- Surge\n - zk/op rollups\n - KZG Ceremony\n - EIP-4844\n - Data Availability Sampling\n - Cross-rollup interop\n- Scourge\n - (very) brief overview of MEV\n - ePBS / Inclusion Lists / MEV Burn\n - Max EB, Stake capping\n- Verge\n - Verkle Trees\n - SNARKify everything:\n - Beacon fast sync\n - Beacon state transition\n - Verkle proofs\n - EVM\n- Purge\n - EIP-4444\n - Protocol simplifications\n- Splurge\n - EIP-1559 endgame\n - Account Abstraction\n - Deep cryptography\n\n## Additional reading and exercises \n\n- [AltExplainer - Ethereum Proof of Stake explained](https://www.youtube.com/watch?v=5gfNUVmX3Es)\n- https://a16zcrypto.com/posts/article/building-helios-ethereum-light-client/\n- https://ethroadmap.com/\n- https://notes.ethereum.org/@domothy/roadmap\n- https://vitalik.eth.limo/general/2021/06/18/verkle.html\n- https://scroll.io/blog/kzg\n- [Ethereum data structures](https://arxiv.org/pdf/2108.05513.pdf)\n- https://ethresear.ch/t/execution-tickets/17944\n- https://notes.ethereum.org/@ipsilon/evm-object-format-overview\n\n### V's overview of the roadmap tracks\n\n- [Merge](https://vitalik.eth.limo/general/2024/10/14/futures1.html)\n- [Surge](https://vitalik.eth.limo/general/2024/10/17/futures2.html)\n- [Scourge](https://vitalik.eth.limo/general/2024/10/20/futures3.html)\n- [Verge](https://vitalik.eth.limo/general/2024/10/23/futures4.html)\n- [Purge](https://vitalik.eth.limo/general/2024/10/26/futures5.html)\n- [Splurge](https://vitalik.eth.limo/general/2024/10/29/futures6.html)" }, { "path": "docs/eps/week6-dev.md", "content": "# Study Group Lecture 6 | Consensus and Execution spec\n\nEPS lecture 6 provides a deeper insight into consensus and execution layer specification. \n\nWatch presentations from [Hsiao-Wei](https://twitter.com/icebearhww) and [Sam](https://twitter.com/_SamWilsn_) on StreamEth or Youtube. Slides are available for both [consensus specs](https://github.com/eth-protocol-fellows/protocol-studies/blob/main/docs/eps/presentations/week6_cl_specs.pdf) and [execution specs](https://github.com/eth-protocol-fellows/protocol-studies/blob/main/docs/eps/presentations/week6_el_specs.pdf) talks.\n\n\n\n## Pre-reading\n\nBefore starting with the lecture 6 content, make yourself familiar with resources in previous days, especially 1-3. \n\nAdditionally, you can read and get ready by studying the following resources:\n\n- Consensus specs:\n - Index: https://github.com/ethereum/consensus-specs\n - Pyspec tutorial: https://github.com/ethereum/consensus-specs/blob/dev/tests/README.md\n- Execution specs:\n - https://blog.ethereum.org/2023/08/29/eel-spec\n - https://github.com/ethereum/execution-specs\n\n## Outline\n\n- Hsiao-Wei Wang on Consensus specs\n- Sam Wilson on EELS\n\n## Additional reading and exercises \n\n- Following instructions from Hsiao-Wei's talk, write and run your own pyspec program\n- As an exercise for EL specs, follow Sam's demo on adding an opcode and add your own\n- https://ethereum.org/en/developers/tutorials/yellow-paper-evm/\n- Vitalik Buterin’s Annotated spec: https://github.com/ethereum/annotated-spec\n- Ben Edgington’s Upgrading Ethereum Book: https://eth2book.info\n" }, { "path": "docs/eps/week6-research.md", "content": "# Study Group Lecture 11 | Sharding and DAS\n\nLecture 11 is going to be a dive into data availability sampling and danksharding. \n\nWatch the presentation by [Dankrad](https://twitter.com/dankrad) on StreamEth or Youtube. Slides are [available here](https://github.com/eth-protocol-fellows/protocol-studies/blob/main/docs/eps/presentations/week6_research.pdf). \n\n\n\n## Pre-reading\n\nBefore starting with the lecture 11 content, make yourself familiar with resources in the introductory week. \n\nAdditionally, you can read and get ready by studying the following resources:\n\n- [Data availability problem](https://www.youtube.com/watch?v=OJT_fR7wexw)\n- [Sharding and DAS proposal](https://hackmd.io/@vbuterin/sharding_proposal)\n\n## Outline\n\n- Ethereum scalability\n- History of sharding and path forward\n- Data availability\n\n## Additional reading and exercises \n\n- [Foundations of Data Availability Sampling](https://www.youtube.com/watch?v=KUNE3kR1kwU)\n- [Design choices in DAS](https://www.youtube.com/watch?v=Al7Jns8bCO4)\n- [Danksharding workshop, Devcon Bogota](https://www.youtube.com/watch?v=8L2C6RDMV9Q)\n- [Fraud and DA proofs paper](https://arxiv.org/abs/1809.09044)\n- [WIP DAS proposal](https://hackmd.io/@vbuterin/das)\n- [PeerDAS](https://epf.wiki/#/wiki/research/peerdas)\n" }, { "path": "docs/eps/week7-dev.md", "content": "# Study Group Lecture 7 | Execution client architecture\n\nDay 7 development track is an insight into Ethereum execution layer client codebase, explaining its architecture and highlighting novel approaches. \n\nWatch the presentation recording by [Dragan](https://twitter.com/rakitadragan) on StreamEth or Youtube. Slides are [available here](https://github.com/eth-protocol-fellows/protocol-studies/blob/main/docs/eps/presentations/week7-dev.pdf). \n\n\n\n## Pre-reading\n\nBefore starting with the lecture 7 development content, make yourself familiar with resources in previous days, especially Day 3 on EL. The execution client intro provided an important knowledge about execution client and its main features with examples from geth codebase. This talk will be diving into reth client design which is written in rust and developed with a modern design approach to EL clients. \n\nAdditionally, you can read and get ready by studying the following resources:\n\n- Reth docs https://paradigmxyz.github.io/reth/\n- Intro to Reth by Georgios https://www.youtube.com/watch?v=zntRpCKHyDc\n- Deeper insight by Dragan https://www.youtube.com/watch?v=pxhq7YrySRM\n\n## Outline\n\n- Reth client \n- Design and architecture\n- Codebase overview, examples \n- Features and highlights \n\n## Additional reading and exercises \n\n- Erigon is a fork of geth which pioneered the design approached implemented by reth. Kind of a middle ground between geth and reth, it's a great source of resources about novel execution client designs\n- As an exercise, run reth and set different `DEBUG` options to explore how various client components operate on lower level" }, { "path": "docs/eps/week7-research.md", "content": "# Study Group Lecture 12 | Verkle Trees\n\nLecture 12 is a research talk focused on verkle trees, an important domain of current research and development aiming to replace the MPT and enable statelessness.\n\nWatch the talk by [Guillaume](https://twitter.com/gballet/), [Ignacio](https://twitter.com/ignaciohagopian) and [Josh](https://twitter.com/rudolf6_) on StreamEth or Youtube. Slides are [available here](https://github.com/eth-protocol-fellows/protocol-studies/blob/main/docs/eps/presentations/week7-research.pdf). \n\n\n\n## Pre-reading\n\nBefore starting with the content, make yourself familiar with resources in previous weeks, especially Day 3 and other content focused on execution layer. You should have at least understanding of merkle trees and current data structures in Ethereum.\n\nAdditionally, you can read and get ready by studying the following resources:\n\n- [Data structures in Ethereum](/wiki/EL/data-structures.md)\n- [Guillaume Ballet - The Verge](https://www.youtube.com/watch?v=F1Ne19Vew6w)\n\n## Outline\n\n- The Verge, motivation and benefits\n- Verkle cryptography\n- Data structures\n- Gas pricing \n- Transitioning the state tree to verkle \n- Current state and challenges \n- Questions from audience\n\n## Additional reading and exercises \n\n- [Stateless book](https://stateless.fyi)\n- [Anatomy of a verkle proof](https://ihagopian.com/posts/anatomy-of-a-verkle-proof)\n- Overview of many various resources https://verkle.info\n- Checkout [verkle implementers calls](https://github.com/ethereum/pm/issues/977)\n" }, { "path": "docs/eps/week8-dev.md", "content": "# Study Group Lecture 8 | Consensus client architecture\n\nThe lecture 8 development track provides a look into Ethereum consensus layer client codebase, explaining its architecture and functions. \n\nWatch the presentation recording by [Paul Harris](https://twitter.com/rolfyone) on StreamEth or Youtube. Slides are [available here](https://github.com/eth-protocol-fellows/protocol-studies/blob/main/docs/eps/presentations/week8-dev.pdf). \n\n\n\n## Pre-reading\n\nBefore starting with the week 8 development content, make yourself familiar with resources in previous weeks, especially day 2 resources on consensus layer. \n\nPaul dives into Teku, consensus client implementation in Java and explains an example on how an EIP gets implemented. You should have at least basic knowledge of the language syntax to follow properly. \n\n[Consensus-specs](https://github.com/ethereum/consensus-specs/) is executable, and a passing knowledge of python may be beneficial, but it's a fairly easy language to reason about at the level the specs are written.\n\nAdditionally, you can get ready by studying the following resources:\n\n- [Post-Merge Ethereum Client Architecture by Adrian Sutton](https://www.youtube.com/watch?v=6d4pkhL37Ao)\n- [Teku Architecture, 2020](https://www.youtube.com/watch?v=1PHZHpVPLk4)\n- [Teku docs](https://docs.teku.consensys.io/)\n\n## Outline\n\n- Teku CL client\n- Brief introduction into our rest api's, declarative framework\n- A look at development process EIP -> spec -> code\n - Examples of EIP-7251 (maxEB)\n\n## Additional reading and exercises \n- [Teku github](https://github.com/Consensys/teku)\n- [Teku code conventions for contributors](https://wiki.hyperledger.org/display/BESU/Coding+Conventions) \n- [Teku and the Merge, PEEPanEIP#83](https://www.youtube.com/watch?v=YTWaZ-NBpbM)\n- [EIP 7251 - Max EB](https://github.com/ethereum/consensus-specs/tree/dev/specs/_features/eip7251)\n- [Beacon-api](https://github.com/ethereum/beacon-APIs)\n- [Lighthouse Consensus Client architecture](https://www.youtube.com/watch?v=pLHhTh_vGZ0) - A similar talk on CL client architecture in Rust client Lighthouse\n" }, { "path": "docs/eps/week8-research.md", "content": "# Study Group Lecture 13 | Protocol services\n\nThis research talk is dedicated to MEV and censorship resistance, discusses the current state and proposals being worked on. \n\nWatch the presentation by [Barnabé Monnot](https://twitter.com/barnabemonnot) on StreamETH channel or Youtube. Slides are [available here](https://github.com/eth-protocol-fellows/protocol-studies/blob/main/docs/eps/presentations/week8-research.pdf). \n\n\n\n## Pre-reading\n\nBefore starting with the content, make yourself familiar with resources in previous weeks, especially Day 5 on roadmap. It's important to understand the current architecture of the protocol, existence of MEV and implications of PBS.\n\nAdditionally, you can get ready by studying the following resources:\n\n- [MEV basics](https://ethereum.org/en/developers/docs/mev/)\n- [RIG projects](https://rig.ethereum.org/)\n- [Wiki on MEV and PBS](https://epf.wiki/#/wiki/research/PBS/pbs)\n\n## Outline\n\n- Protocol services and impact of MEV, cryptoeconomics\n- PBS and related proposals \n- ePBS flavors\n- MEV burn\n- Rainbow staking \n \n## Additional reading and exercises \n\n- [Rig Open Problems](https://efdn.notion.site/RIG-Open-Problems-ROPs-c11382c213f949a4b89927ef4e962adf)\n- [Censorship stats](https://dotpics.info/)\n- [Rainbow staking](https://ethresear.ch/t/unbundling-staking-towards-rainbow-staking/)\n- [Notes on PBS](https://barnabe.substack.com/p/pbs)" }, { "path": "docs/eps/week9-dev.md", "content": "# Study Group Lecture 9 | Local testing and prototyping \n\nThis development talk is dedicated to testing and prototyping forks locally, it discusses the current state and ideas being worked on. \n\nWatch the presentation by [Parithosh](https://twitter.com/parithosh_j) on StreamETH channel or Youtube. Slides are [available here](https://github.com/eth-protocol-fellows/protocol-studies/blob/main/docs/eps/presentations/week9-dev.pdf). \n\n\n\n## Pre-reading\n\nBefore starting with the day 9 content, make yourself familiar with resources in previous weeks, especially day 4 presentation on testing and the node workshop. It's important to understand the current architecture of the protocol and its basic tooling. \n\nAdditionally, you can get ready by studying the following resources:\n- [Quest for the Best Tests, a Retrospective on #TestingTheMerge by Pari](https://archive.devcon.org/archive/watch/6/quest-for-the-best-tests-a-retrospective-on-testingthemerge/?tab=YouTube)\n- [Dencun testing](https://www.youtube.com/watch?v=88tZticGbTo)\n\n## Preparation\n- [Install kurtosis and docker on your system](https://docs.kurtosis.com/quickstart/)\n\n## Outline\n\n- What do we test and why?\n- Importance of Local testing\n- How can I prototype a tool or change?\n- What are devnets? How do we spin them up?\n- Shadow forks \n- Handy devops tools\n - Kurtosis\n - Template-devnets\n - Assertoor\n - Forky\n - Tracoor\n - Dora\n - Goomy-blob\n - Xatu\n- Run your own local devnet and shadowfork!\n\n## Additional reading and exercises\n- [Attacknet: Chaos engineering on Ethereum](https://ethpandaops.io/posts/attacknet-introduction/)\n- [Verkle devnets](https://github.com/ethpandaops/verkle-devnets)\n- [Kurtosis](https://github.com/kurtosis-tech/kurtosis)\n- Follow exercises proposed by Pari in the talk\n - Modify a client with a custom log message and run it using Kurtosis\n - Deploy some of the tolling, connect to your own node on any network " }, { "path": "docs/eps/week9-research.md", "content": "# Study Group Lecture 14 | Purge and Portal Network\n\nThis talk is focused on history expiry and dives into Portal Network, an overlay network for light clients enabling alternative access to current and historical data. \n\nWatch the presentation by [Piper Merriam](https://twitter.com/parithosh_j), on [StreamEth](https://streameth.org/65cf97e702e803dbd57d823f/epf_study_group) and [Youtube](https://www.youtube.com/@ethprotocolfellows/streams).\n\n\n\n## Pre-reading\n\nBefore starting with this research content, make yourself familiar with resources in previous weeks, especially day 5 presentation on roadmap. You should understand the execution client database structure, the difference between ancient and current data. \n\nAdditionally, you can get ready by studying the following resources:\n- [Decentralizing access to Ethereum utilizing Ethereum's Portal Networks](https://www.youtube.com/watch?v=LZ_yWmm7ISg)\n- [Statelessness and history expiry, Ethereum.org](https://ethereum.org/en/roadmap/statelessness/)\n- [Portal Network web](https://www.ethportal.net/)\n- [EL Data structure](https://epf.wiki/#/wiki/EL/data-structures)\n\n## Outline\n\n- History expiry in Ethereum execution clients\n- Portal Network\n\n## Additional reading and exercises\n\n- EIP-4444\n - https://eips.ethereum.org/EIPS/eip-4444\n- SELFDESTRUCT Removal EIPS (many are stale)\n - https://eips.ethereum.org/EIPS/eip-6049\n - https://eips.ethereum.org/EIPS/eip-6780\n - https://eips.ethereum.org/EIPS/eip-2936\n - https://eips.ethereum.org/EIPS/eip-4758\n - https://eips.ethereum.org/EIPS/eip-4760\n - https://eips.ethereum.org/EIPS/eip-6046\n - https://eips.ethereum.org/EIPS/eip-6190\n - EOF things: https://hackmd.io/@shemnon/mega-eof-scoping\n- LOG reform\n - https://eips.ethereum.org/EIPS/eip-7668\n - https://github.com/ethereum/EIPs/pull/8368\n- Address Space Extension\n - https://github.com/ethereum/EIPs/pull/8385\n - https://ethereum-magicians.org/t/thoughts-on-address-space-extension-ase/6779\n - https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bytes/5485\n - https://notes.ethereum.org/@ipsilon/address-space-extension-exploration\n- State Expiry\n - https://notes.ethereum.org/@vbuterin/verkle_and_state_expiry_proposal\n - https://medium.com/@chaisomsri96/statelessness-series-part1-state-expiry-history-expiry-2bbd5835b329 (did not fully vet this article)\n - https://notes.ethereum.org/@vbuterin/state_expiry_eip\n - https://hackmd.io/@vbuterin/state_expiry_paths\n- General Stateless Roadmap Things\n - https://ethereum.org/en/roadmap/statelessness/\n- [The Portal Network, EthZurich 2023](https://www.youtube.com/watch?v=8MUii5W2sMc)\n" }, { "path": "docs/images/el-architecture/excalidraw/architecture-overview.excalidraw", "content": "{\n \"type\": \"excalidraw\",\n \"version\": 2,\n \"source\": \"https://excalidraw.com\",\n \"elements\": [\n {\n \"type\": \"rectangle\",\n \"version\": 797,\n \"versionNonce\": 60131825,\n \"index\": \"a0\",\n \"isDeleted\": false,\n \"id\": \"FgnJAxXImgOttHQte_VsE\",\n \"fillStyle\": \"cross-hatch\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -79.51630360553872,\n \"y\": -1303.754307345403,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 1841.0260942760947,\n \"height\": 1316.284511784512,\n \"seed\": 682175889,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"ahJ_cggX7F0YHMM_pbJGW\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"sdfMrpyc0u1fhYG6O2TT8\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713651115654,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 448,\n \"versionNonce\": 125171815,\n \"index\": \"a1\",\n \"isDeleted\": false,\n \"id\": \"Ep55d2Cf-CSI4chXklNiC\",\n \"fillStyle\": \"cross-hatch\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"dotted\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -15.123205962440807,\n \"y\": -1235.2963948874904,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 413.9333190917969,\n \"height\": 131.5151515151518,\n \"seed\": 77882257,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713645887681,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 52.60606060606073,\n \"fontFamily\": 1,\n \"text\": \"Execution Layer\\nClient\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Execution Layer\\nClient\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 703,\n \"versionNonce\": 625709323,\n \"index\": \"a2\",\n \"isDeleted\": false,\n \"id\": \"-_n9K0bgJ-oFtpjnnaeuP\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 737.0383746531147,\n \"y\": -1478.8204535313052,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#ffffff\",\n \"width\": 710.5591601287589,\n \"height\": 242.53752665728297,\n \"seed\": 934851487,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"yWvcQG8ffdBZzyiM_qK_P\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"cgedGQ2MpgS37v5sDsFEt\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"oyy3j29cSLay83iHEhw17\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"7USdFW4_bZpzRgVlW3g8j\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"wfy94yFqMcaX4bwE-QRva\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713692334657,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 572,\n \"versionNonce\": 433685545,\n \"index\": \"a3\",\n \"isDeleted\": false,\n \"id\": \"fwUQ5JxGxHDp1vWBsJtIY\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 998.5241455804984,\n \"y\": -1384.0792321808042,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#ffffff\",\n \"width\": 198.48333740234375,\n \"height\": 47.37061067525058,\n \"seed\": 1960518911,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713645360732,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 37.896488540200465,\n \"fontFamily\": 1,\n \"text\": \"Engine API\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Engine API\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 458,\n \"versionNonce\": 1145423083,\n \"index\": \"a4\",\n \"isDeleted\": false,\n \"id\": \"RumOeXmWSLBfwsZcLG0Ib\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 622.7553886558729,\n \"y\": -1887.3709956440623,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#ffffff\",\n \"width\": 656.8329403134411,\n \"height\": 206.8698640352651,\n \"seed\": 1266240017,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"Zf4mRJJoTDzwpc0yfrPdJ\"\n },\n {\n \"id\": \"yWvcQG8ffdBZzyiM_qK_P\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"cgedGQ2MpgS37v5sDsFEt\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"wfy94yFqMcaX4bwE-QRva\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"UP-MOsA8gwhg1R_pdOqQA\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713692590649,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 655,\n \"versionNonce\": 1018425227,\n \"index\": \"a5\",\n \"isDeleted\": false,\n \"id\": \"Zf4mRJJoTDzwpc0yfrPdJ\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 816.771864916109,\n \"y\": -1804.706425587743,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#ffffff\",\n \"width\": 268.79998779296875,\n \"height\": 41.54072392262643,\n \"seed\": 1537561009,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713692590649,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 33.232579138101144,\n \"fontFamily\": 1,\n \"text\": \"Consensus Layer\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"RumOeXmWSLBfwsZcLG0Ib\",\n \"originalText\": \"Consensus Layer\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"arrow\",\n \"version\": 1399,\n \"versionNonce\": 1254796075,\n \"index\": \"a6\",\n \"isDeleted\": false,\n \"id\": \"yWvcQG8ffdBZzyiM_qK_P\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 688.3267411620876,\n \"y\": -1661.6333514274675,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#ffffff\",\n \"width\": 67.95254061145954,\n \"height\": 180.50855145652986,\n \"seed\": 1656084337,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1713692590801,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"RumOeXmWSLBfwsZcLG0Ib\",\n \"gap\": 18.86778018132975,\n \"focus\": 0.8408891754451592\n },\n \"endBinding\": {\n \"elementId\": \"-_n9K0bgJ-oFtpjnnaeuP\",\n \"gap\": 2.3043464396322406,\n \"focus\": -0.7221175569428874\n },\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 67.95254061145954,\n 180.50855145652986\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 441,\n \"versionNonce\": 2058471429,\n \"index\": \"a7\",\n \"isDeleted\": false,\n \"id\": \"5vMkLSuRPwUEVKTPUe0my\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 139.85743376819846,\n \"y\": -1601.5655462184927,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#ffffff\",\n \"width\": 488.54998779296875,\n \"height\": 60.2886094333353,\n \"seed\": 997404593,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713692601618,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 48.23088754666824,\n \"fontFamily\": 1,\n \"text\": \"Fork Choice Updated\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Fork Choice Updated\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"arrow\",\n \"version\": 1628,\n \"versionNonce\": 18260261,\n \"index\": \"a8\",\n \"isDeleted\": false,\n \"id\": \"wfy94yFqMcaX4bwE-QRva\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1278.39677039075,\n \"y\": -1657.3022780622487,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#ffffff\",\n \"width\": 54.14162647342914,\n \"height\": 171.15506728415016,\n \"seed\": 640989535,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1713692611453,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"RumOeXmWSLBfwsZcLG0Ib\",\n \"focus\": -0.7951758806729825,\n \"gap\": 23.19885354654832\n },\n \"endBinding\": {\n \"elementId\": \"-_n9K0bgJ-oFtpjnnaeuP\",\n \"focus\": 0.7135929321504012,\n \"gap\": 7.326757246793136\n },\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 54.14162647342914,\n 171.15506728415016\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 481,\n \"versionNonce\": 1284498655,\n \"index\": \"a9\",\n \"isDeleted\": false,\n \"id\": \"eoIolPKii-W42lyrCVYJq\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1374.0812249377786,\n \"y\": -1615.928160485641,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#ffffff\",\n \"width\": 332.8166809082031,\n \"height\": 67.65203610256302,\n \"seed\": 1530148223,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713651011383,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 54.121628882050416,\n \"fontFamily\": 1,\n \"text\": \"New Payload\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"New Payload\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 943,\n \"versionNonce\": 310655761,\n \"index\": \"aB\",\n \"isDeleted\": false,\n \"id\": \"9WftG63CbFTg3zXGmE1gj\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 982.9070970678624,\n \"y\": -388.8797282208235,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#ffffff\",\n \"width\": 311.2525252525253,\n \"height\": 150.5117845117845,\n \"seed\": 1055281215,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"k85HAs2-fRVZEpNaMr_HV\"\n }\n ],\n \"updated\": 1713649560134,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 1106,\n \"versionNonce\": 546001365,\n \"index\": \"aC\",\n \"isDeleted\": false,\n \"id\": \"k85HAs2-fRVZEpNaMr_HV\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1088.0833589311856,\n \"y\": -331.88982923092453,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#ffffff\",\n \"width\": 100.9000015258789,\n \"height\": 36.531986531986526,\n \"seed\": 222591857,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713645299689,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 29.22558922558922,\n \"fontFamily\": 1,\n \"text\": \"State \",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"9WftG63CbFTg3zXGmE1gj\",\n \"originalText\": \"State \",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 579,\n \"versionNonce\": 1100293099,\n \"index\": \"aF\",\n \"isDeleted\": false,\n \"id\": \"siyDzSseEQqfwuq3Ld5-8\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1144.418039828805,\n \"y\": -924.2231625642576,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#ffffff\",\n \"width\": 338.71380471380485,\n \"height\": 178.5117845117845,\n \"seed\": 1542700204,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"fQFs3BHcETUS_5GsrhIOW\"\n },\n {\n \"id\": \"rKrBxlo7-js0XwcTZ3yMG\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"vNTiR5kjltlr0bU8DX0Yy\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"rSKoByNvrhoMVNZ9RyW-Q\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"7USdFW4_bZpzRgVlW3g8j\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713692210101,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 680,\n \"versionNonce\": 2082176159,\n \"index\": \"aG\",\n \"isDeleted\": false,\n \"id\": \"fQFs3BHcETUS_5GsrhIOW\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1285.166608598061,\n \"y\": -853.2332635743586,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#ffffff\",\n \"width\": 57.21666717529297,\n \"height\": 36.531986531986526,\n \"seed\": 1210097964,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713650983949,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 29.22558922558922,\n \"fontFamily\": 1,\n \"text\": \"EVM\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"siyDzSseEQqfwuq3Ld5-8\",\n \"originalText\": \"EVM\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 338,\n \"versionNonce\": 2127463275,\n \"index\": \"aH\",\n \"isDeleted\": false,\n \"id\": \"LZV38R3EJgoGZG019rwHk\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 337.8456492564144,\n \"y\": -937.9133982544932,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#ffffff\",\n \"width\": 344.86195286195283,\n \"height\": 140.2828282828283,\n \"seed\": 96817812,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"DmJWi8FyJpsvevqYvrVm8\"\n },\n {\n \"id\": \"XGVWIZ6pHUIj7ulOBYe4A\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"loU3AR_BS_RxH89duKDtv\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713692643944,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 472,\n \"versionNonce\": 2019820817,\n \"index\": \"aI\",\n \"isDeleted\": false,\n \"id\": \"DmJWi8FyJpsvevqYvrVm8\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 344.2682943885627,\n \"y\": -886.0379773790723,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#ffffff\",\n \"width\": 332.01666259765625,\n \"height\": 36.531986531986526,\n \"seed\": 1790106796,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713649448607,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 29.22558922558922,\n \"fontFamily\": 1,\n \"text\": \"Transactions (mempool)\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"LZV38R3EJgoGZG019rwHk\",\n \"originalText\": \"Transactions (mempool)\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"arrow\",\n \"version\": 1549,\n \"versionNonce\": 1969692213,\n \"index\": \"aJ\",\n \"isDeleted\": false,\n \"id\": \"XGVWIZ6pHUIj7ulOBYe4A\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 146.13773735681042,\n \"y\": -377.16255650365173,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#ffffff\",\n \"width\": 332.9662081995817,\n \"height\": 394.01010101010064,\n \"seed\": 1103704340,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1714326038458,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"ZuasuskvUFGU2ZdFZUvPC\",\n \"focus\": -0.023530779804662776,\n \"gap\": 1.0000000000000284\n },\n \"endBinding\": {\n \"elementId\": \"LZV38R3EJgoGZG019rwHk\",\n \"focus\": 0.029267874339474285,\n \"gap\": 26.45791245791264\n },\n \"lastCommittedPoint\": null,\n \"startArrowhead\": \"arrow\",\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 262.7516829433754,\n -128.87878787878805\n ],\n [\n 332.9662081995817,\n -394.01010101010064\n ]\n ]\n },\n {\n \"type\": \"arrow\",\n \"version\": 2489,\n \"versionNonce\": 635474111,\n \"index\": \"aK\",\n \"isDeleted\": false,\n \"id\": \"rKrBxlo7-js0XwcTZ3yMG\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1086.071305053363,\n \"y\": -397.6474049885003,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#ffffff\",\n \"width\": 121.22452715889426,\n \"height\": 340.3737373737372,\n \"seed\": 1925180692,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1713650983949,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": {\n \"elementId\": \"siyDzSseEQqfwuq3Ld5-8\",\n \"focus\": 0.3577093555894991,\n \"gap\": 7.690235690235681\n },\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 121.22452715889426,\n -340.3737373737372\n ]\n ]\n },\n {\n \"type\": \"arrow\",\n \"version\": 2488,\n \"versionNonce\": 1512972511,\n \"index\": \"aL\",\n \"isDeleted\": false,\n \"id\": \"vNTiR5kjltlr0bU8DX0Yy\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1311.780417882047,\n \"y\": -743.8662602073551,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#ffffff\",\n \"width\": 128.05919426723335,\n \"height\": 341.8350168350165,\n \"seed\": 1032799072,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1713650983949,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"siyDzSseEQqfwuq3Ld5-8\",\n \"focus\": -0.1584561724991774,\n \"gap\": 1.8451178451178976\n },\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -128.05919426723335,\n 341.8350168350165\n ]\n ]\n },\n {\n \"type\": \"rectangle\",\n \"version\": 577,\n \"versionNonce\": 1760790335,\n \"index\": \"aN\",\n \"isDeleted\": false,\n \"id\": \"jndv3wQ06fQYQtwacZJxs\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 2217.5392519500174,\n \"y\": -1107.456327547423,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#ffffff\",\n \"width\": 317.0976430976431,\n \"height\": 173.89225589225586,\n \"seed\": 2105684640,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"zzftImsqwKd5mau51GjTp\"\n },\n {\n \"id\": \"ahJ_cggX7F0YHMM_pbJGW\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"sdfMrpyc0u1fhYG6O2TT8\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713650901831,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 746,\n \"versionNonce\": 1553876831,\n \"index\": \"aO\",\n \"isDeleted\": false,\n \"id\": \"zzftImsqwKd5mau51GjTp\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 2301.8714063235457,\n \"y\": -1038.7761928672883,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#ffffff\",\n \"width\": 148.43333435058594,\n \"height\": 36.531986531986526,\n \"seed\": 1556900704,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713650901831,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 29.22558922558922,\n \"fontFamily\": 1,\n \"text\": \"User/web3\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"jndv3wQ06fQYQtwacZJxs\",\n \"originalText\": \"User/web3\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"arrow\",\n \"version\": 2210,\n \"versionNonce\": 868123057,\n \"index\": \"aP\",\n \"isDeleted\": false,\n \"id\": \"ahJ_cggX7F0YHMM_pbJGW\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1777.5838647446299,\n \"y\": -1048.098014139116,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#ffffff\",\n \"width\": 438.95538720538707,\n \"height\": 1.119699798925467,\n \"seed\": 1418290848,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1713651115655,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"FgnJAxXImgOttHQte_VsE\",\n \"focus\": -0.6053760677593353,\n \"gap\": 16.074074074073906\n },\n \"endBinding\": {\n \"elementId\": \"jndv3wQ06fQYQtwacZJxs\",\n \"focus\": 0.3333063507641485,\n \"gap\": 1\n },\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 438.95538720538707,\n -1.119699798925467\n ]\n ]\n },\n {\n \"type\": \"arrow\",\n \"version\": 2069,\n \"versionNonce\": 1549568369,\n \"index\": \"aQ\",\n \"isDeleted\": false,\n \"id\": \"sdfMrpyc0u1fhYG6O2TT8\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 2216.539251950017,\n \"y\": -957.5147603326811,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#ffffff\",\n \"width\": 436.86784511784435,\n \"height\": 7.548628141068548,\n \"seed\": 1036659360,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1713651115655,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"jndv3wQ06fQYQtwacZJxs\",\n \"focus\": -0.6744593720748839,\n \"gap\": 1\n },\n \"endBinding\": {\n \"elementId\": \"FgnJAxXImgOttHQte_VsE\",\n \"focus\": -0.42746932116609937,\n \"gap\": 18.161616161616394\n },\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -436.86784511784435,\n 7.548628141068548\n ]\n ]\n },\n {\n \"type\": \"ellipse\",\n \"version\": 441,\n \"versionNonce\": 1291598965,\n \"index\": \"aQV\",\n \"isDeleted\": false,\n \"id\": \"jvMQXbQZG3ErjC616pYO3\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -208.27892986816528,\n \"y\": -337.2332635743587,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#ffffff\",\n \"width\": 68.68013468013469,\n \"height\": 70.14141414141417,\n \"seed\": 1567195808,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [\n {\n \"id\": \"yTHLUCYwtFkDM98RX9Tx0\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"kofqDTcbmGMFtvTWA-kFY\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"dtRi2_WvVx9qE1iqfIBOh\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1714326038457,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 324,\n \"versionNonce\": 1782731911,\n \"index\": \"aR\",\n \"isDeleted\": false,\n \"id\": \"SsGFuKAkHHuDpn9yglxHA\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1903.0914405022054,\n \"y\": -1165.4908393319347,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#ffffff\",\n \"width\": 146.3333282470703,\n \"height\": 73.06397306397305,\n \"seed\": 409693856,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713712613620,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 29.22558922558922,\n \"fontFamily\": 1,\n \"text\": \"JSON-RPC\\nAPI\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"JSON-RPC\\nAPI\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 521,\n \"versionNonce\": 1099429728,\n \"index\": \"aW\",\n \"isDeleted\": false,\n \"id\": \"WZ1OySPIFvJslAPB2le4-\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -835.0085232545506,\n \"y\": -525.7436050847006,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#ffffff\",\n \"width\": 203.00000000000003,\n \"height\": 181.00000000000003,\n \"seed\": 2022512480,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [],\n \"updated\": 1713626390092,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"ellipse\",\n \"version\": 610,\n \"versionNonce\": 692303953,\n \"index\": \"aZ\",\n \"isDeleted\": false,\n \"id\": \"lHyPbfMUjuBAA6Zt54TWy\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -576.5085232545504,\n \"y\": -458.74360508470056,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#ffffff\",\n \"width\": 47,\n \"height\": 48.00000000000002,\n \"seed\": 1798642336,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1713649560134,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 557,\n \"versionNonce\": 476275867,\n \"index\": \"ac\",\n \"isDeleted\": false,\n \"id\": \"fFWLOSLgy80eyWjrvAiow\",\n \"fillStyle\": \"cross-hatch\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"dotted\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -822.7501919557224,\n \"y\": -502.2436050847007,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 177.14999389648438,\n \"height\": 20.000000000000043,\n \"seed\": 781639520,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713642487815,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 16.000000000000036,\n \"fontFamily\": 1,\n \"text\": \"Execution Layer Client\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Execution Layer Client\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"arrow\",\n \"version\": 481,\n \"versionNonce\": 1390284155,\n \"index\": \"ad\",\n \"isDeleted\": false,\n \"id\": \"kofqDTcbmGMFtvTWA-kFY\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -205.35637094560593,\n \"y\": -337.23326357435883,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#ffffff\",\n \"width\": 105.2121212121212,\n \"height\": 70.14141414141415,\n \"seed\": 1477338784,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1714326039812,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"jvMQXbQZG3ErjC616pYO3\",\n \"focus\": 0.33727771334282786,\n \"gap\": 12.343479248160179\n },\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -105.2121212121212,\n -70.14141414141415\n ]\n ]\n },\n {\n \"type\": \"arrow\",\n \"version\": 629,\n \"versionNonce\": 5547547,\n \"index\": \"ae\",\n \"isDeleted\": false,\n \"id\": \"yTHLUCYwtFkDM98RX9Tx0\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -209.5006857934975,\n \"y\": -276.63104372455405,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#ffffff\",\n \"width\": 102.28956228956228,\n \"height\": 89.13804713804723,\n \"seed\": 140633952,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1714326039812,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"jvMQXbQZG3ErjC616pYO3\",\n \"focus\": 0.11838961774399336,\n \"gap\": 9.193005139639233\n },\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -102.28956228956228,\n 89.13804713804723\n ]\n ]\n },\n {\n \"type\": \"arrow\",\n \"version\": 480,\n \"versionNonce\": 1085221563,\n \"index\": \"af\",\n \"isDeleted\": false,\n \"id\": \"dtRi2_WvVx9qE1iqfIBOh\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -206.81765040688538,\n \"y\": -303.62383596493123,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#ffffff\",\n \"width\": 135.8989898989899,\n \"height\": 4.383838383838384,\n \"seed\": 1051586400,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1714326039813,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"jvMQXbQZG3ErjC616pYO3\",\n \"focus\": 0.011419036349284633,\n \"gap\": 1\n },\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -135.8989898989899,\n -4.383838383838384\n ]\n ]\n },\n {\n \"type\": \"arrow\",\n \"version\": 168,\n \"versionNonce\": 567553777,\n \"index\": \"ag\",\n \"isDeleted\": false,\n \"id\": \"mL6evWfetVINJ5E-_LgXy\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -537.0085232545503,\n \"y\": -446.7436050847006,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#ffffff\",\n \"width\": 63,\n \"height\": 33,\n \"seed\": 2066973536,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1713649560134,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 63,\n -33\n ]\n ]\n },\n {\n \"type\": \"arrow\",\n \"version\": 170,\n \"versionNonce\": 878175921,\n \"index\": \"ah\",\n \"isDeleted\": false,\n \"id\": \"UK-8ADGFG4HIipY8odehX\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -530.0085510738254,\n \"y\": -425.7436061411288,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#ffffff\",\n \"width\": 79,\n \"height\": 3,\n \"seed\": 834510688,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1713649560134,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 79,\n 3\n ]\n ]\n },\n {\n \"type\": \"arrow\",\n \"version\": 180,\n \"versionNonce\": 2007019121,\n \"index\": \"ai\",\n \"isDeleted\": false,\n \"id\": \"6zoGLQB0EVY9RFQVoob81\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -531.008776083554,\n \"y\": -410.7438530516081,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#ffffff\",\n \"width\": 52,\n \"height\": 51,\n \"seed\": 1972976480,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1713649560134,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 52,\n 51\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 168,\n \"versionNonce\": 1013480885,\n \"index\": \"aj\",\n \"isDeleted\": false,\n \"id\": \"Q1CZDpTaEEKNTXlFuZNKH\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -522.6751899212168,\n \"y\": -830.6959860370816,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#ffffff\",\n \"width\": 365.6000061035156,\n \"height\": 123.57142857142848,\n \"seed\": 422093664,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1714325608229,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 32.95238095238093,\n \"fontFamily\": 1,\n \"text\": \"Gossips with \\nother exceution lauer \\nclients over p2p\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Gossips with \\nother exceution lauer \\nclients over p2p\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 161,\n \"versionNonce\": 2075760465,\n \"index\": \"an\",\n \"isDeleted\": false,\n \"id\": \"h0UMPfxC0RvkmjuuJYqZX\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -561.7228089688357,\n \"y\": -877.6007479418435,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 404.2857142857141,\n \"height\": 821.4285714285714,\n \"seed\": 2077213344,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [],\n \"updated\": 1713649560134,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"rectangle\",\n \"version\": 570,\n \"versionNonce\": 1830592352,\n \"index\": \"as\",\n \"isDeleted\": false,\n \"id\": \"kJ77Ud1oDkNtQfAmCSgfF\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -811.5010440271093,\n \"y\": -250.95789079898668,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#ffffff\",\n \"width\": 203.00000000000003,\n \"height\": 181.00000000000003,\n \"seed\": 1013433184,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [],\n \"updated\": 1713626837772,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"ellipse\",\n \"version\": 655,\n \"versionNonce\": 589720945,\n \"index\": \"at\",\n \"isDeleted\": false,\n \"id\": \"IpSRjW3SSpqbxheJJ9wfb\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -553.0010440271093,\n \"y\": -183.95789079898668,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#ffffff\",\n \"width\": 47,\n \"height\": 48.00000000000002,\n \"seed\": 358111072,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1713649560134,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"rectangle\",\n \"version\": 833,\n \"versionNonce\": 1941739537,\n \"index\": \"au\",\n \"isDeleted\": false,\n \"id\": \"3xuLPVznyHnd8UiMusUvq\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -704.0010440271093,\n \"y\": -196.45789079898668,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#ffffff\",\n \"width\": 173,\n \"height\": 75,\n \"seed\": 722889568,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"dddX1gBp8YRfQYIRjTM1j\"\n }\n ],\n \"updated\": 1713649560134,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 825,\n \"versionNonce\": 1718420320,\n \"index\": \"av\",\n \"isDeleted\": false,\n \"id\": \"dddX1gBp8YRfQYIRjTM1j\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -650.8760440271093,\n \"y\": -171.45789079898668,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#ffffff\",\n \"width\": 66.75,\n \"height\": 25,\n \"seed\": 133300064,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713626837772,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 20,\n \"fontFamily\": 1,\n \"text\": \"devp2p\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"3xuLPVznyHnd8UiMusUvq\",\n \"originalText\": \"devp2p\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"text\",\n \"version\": 606,\n \"versionNonce\": 944991221,\n \"index\": \"aw\",\n \"isDeleted\": false,\n \"id\": \"C1HcF29EKah0HC2jRu6FC\",\n \"fillStyle\": \"cross-hatch\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"dotted\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -799.2427127282812,\n \"y\": -227.45789079898668,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 177.14999389648438,\n \"height\": 20.000000000000043,\n \"seed\": 1815810912,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713642487815,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 16.000000000000036,\n \"fontFamily\": 1,\n \"text\": \"Execution Layer Client\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Execution Layer Client\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"arrow\",\n \"version\": 269,\n \"versionNonce\": 699041329,\n \"index\": \"ax\",\n \"isDeleted\": false,\n \"id\": \"FCTSXldjZLxl17oAAn8hX\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -513.5010440271091,\n \"y\": -171.95789079898668,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#ffffff\",\n \"width\": 63,\n \"height\": 33,\n \"seed\": 239183712,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1713649560134,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 63,\n -33\n ]\n ]\n },\n {\n \"type\": \"arrow\",\n \"version\": 271,\n \"versionNonce\": 963735025,\n \"index\": \"ay\",\n \"isDeleted\": false,\n \"id\": \"4ByjpP6Anlyk34INGS4P3\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -506.50104402710906,\n \"y\": -150.95789079898668,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#ffffff\",\n \"width\": 79,\n \"height\": 3,\n \"seed\": 1515567968,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1713649560134,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 79,\n 3\n ]\n ]\n },\n {\n \"type\": \"arrow\",\n \"version\": 283,\n \"versionNonce\": 1408993169,\n \"index\": \"az\",\n \"isDeleted\": false,\n \"id\": \"92FlLJPtyjONvTVM-Jp41\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -507.50104402710906,\n \"y\": -135.95789079898668,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#ffffff\",\n \"width\": 52,\n \"height\": 51,\n \"seed\": 851922784,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1713649560134,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 52,\n 51\n ]\n ]\n },\n {\n \"type\": \"rectangle\",\n \"version\": 785,\n \"versionNonce\": 842213585,\n \"index\": \"b00\",\n \"isDeleted\": false,\n \"id\": \"Q_neaG_SS_4zyCGNTssyx\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -727.5085232545505,\n \"y\": -471.2436050847007,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#ffffff\",\n \"width\": 173,\n \"height\": 75,\n \"seed\": 1425454944,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"MObFA4XUeneeC7-L0NgnW\"\n }\n ],\n \"updated\": 1713649560134,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 777,\n \"versionNonce\": 1352912736,\n \"index\": \"b01\",\n \"isDeleted\": false,\n \"id\": \"MObFA4XUeneeC7-L0NgnW\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -674.3835232545505,\n \"y\": -446.2436050847007,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#ffffff\",\n \"width\": 66.75,\n \"height\": 25,\n \"seed\": 669567840,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713626946303,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 20,\n \"fontFamily\": 1,\n \"text\": \"devp2p\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"Q_neaG_SS_4zyCGNTssyx\",\n \"originalText\": \"devp2p\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 557,\n \"versionNonce\": 721928725,\n \"index\": \"b02\",\n \"isDeleted\": false,\n \"id\": \"ZuasuskvUFGU2ZdFZUvPC\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -157.682970272205,\n \"y\": -376.1625565036517,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#ffffff\",\n \"width\": 311.2525252525253,\n \"height\": 150.5117845117845,\n \"seed\": 974232593,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"p_sKc-oXirXqR4NES8oii\"\n },\n {\n \"id\": \"kofqDTcbmGMFtvTWA-kFY\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"dtRi2_WvVx9qE1iqfIBOh\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"XGVWIZ6pHUIj7ulOBYe4A\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"gO_ZMZNq0JV7moXCYXxDJ\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1714326038457,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 720,\n \"versionNonce\": 491829109,\n \"index\": \"b03\",\n \"isDeleted\": false,\n \"id\": \"p_sKc-oXirXqR4NES8oii\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -50.831709171821274,\n \"y\": -319.1726575137527,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#ffffff\",\n \"width\": 97.55000305175781,\n \"height\": 36.531986531986526,\n \"seed\": 1988489713,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1714326038457,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 29.22558922558922,\n \"fontFamily\": 1,\n \"text\": \"devp2p\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"ZuasuskvUFGU2ZdFZUvPC\",\n \"originalText\": \"devp2p\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"arrow\",\n \"version\": 1583,\n \"versionNonce\": 605902027,\n \"index\": \"b0D\",\n \"isDeleted\": false,\n \"id\": \"loU3AR_BS_RxH89duKDtv\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"dotted\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 701.2884709813841,\n \"y\": -870.6359532237345,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 280.63174811383215,\n \"height\": 5.73860424191821,\n \"seed\": 78115291,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1713692643944,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"LZV38R3EJgoGZG019rwHk\",\n \"focus\": 0.05222873095281719,\n \"gap\": 18.580868863016804\n },\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 160.0125295735893,\n -5.73860424191821\n ],\n [\n 280.63174811383215,\n -3.811307998771781\n ]\n ]\n },\n {\n \"type\": \"ellipse\",\n \"version\": 576,\n \"versionNonce\": 1959773393,\n \"index\": \"b0F\",\n \"isDeleted\": false,\n \"id\": \"P6T-wpTtVqt7w-9L9xOh8\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 871.5843338883067,\n \"y\": -550.3464675780124,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 526.0499999999998,\n \"height\": 474.1385767790261,\n \"seed\": 1000265887,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [\n {\n \"id\": \"gO_ZMZNq0JV7moXCYXxDJ\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"rSKoByNvrhoMVNZ9RyW-Q\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713651106735,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 406,\n \"versionNonce\": 1371783295,\n \"index\": \"b0I\",\n \"isDeleted\": false,\n \"id\": \"9hNYaLTExU2uicbLRAovJ\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1127.9956453637164,\n \"y\": -177.4385465366911,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 91.28333282470703,\n \"height\": 44.80459016393443,\n \"seed\": 1129084501,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713650567690,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 35.84367213114754,\n \"fontFamily\": 1,\n \"text\": \"Sync \",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Sync \",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"arrow\",\n \"version\": 591,\n \"versionNonce\": 1856165109,\n \"index\": \"b0R\",\n \"isDeleted\": false,\n \"id\": \"gO_ZMZNq0JV7moXCYXxDJ\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 154.56955498032028,\n \"y\": -270.5291135781252,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 716.992165214437,\n \"height\": 245.33346080458358,\n \"seed\": 1375156071,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1714326038458,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"ZuasuskvUFGU2ZdFZUvPC\",\n \"focus\": 0.6925429285556787,\n \"gap\": 1\n },\n \"endBinding\": {\n \"elementId\": \"P6T-wpTtVqt7w-9L9xOh8\",\n \"focus\": -0.9640547333755998,\n \"gap\": 13.968990426059236\n },\n \"lastCommittedPoint\": null,\n \"startArrowhead\": \"arrow\",\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 470.5647789079866,\n -209.42877722086104\n ],\n [\n 716.992165214437,\n 35.904683583722544\n ]\n ]\n },\n {\n \"type\": \"arrow\",\n \"version\": 1927,\n \"versionNonce\": 1379524133,\n \"index\": \"b0v\",\n \"isDeleted\": false,\n \"id\": \"rSKoByNvrhoMVNZ9RyW-Q\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1358.4531306750916,\n \"y\": -177.89835620523252,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 78.73412508050706,\n \"height\": 579.9038380254881,\n \"seed\": 964284913,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1713692742604,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"P6T-wpTtVqt7w-9L9xOh8\",\n \"focus\": 0.9600381842899018,\n \"gap\": 6.320086565806548\n },\n \"endBinding\": {\n \"elementId\": \"siyDzSseEQqfwuq3Ld5-8\",\n \"focus\": -0.7323075896001114,\n \"gap\": 1\n },\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 60.681203213214985,\n -230.05953459375348\n ],\n [\n 78.73412508050706,\n -579.9038380254881\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 155,\n \"versionNonce\": 1949423633,\n \"index\": \"b0w\",\n \"isDeleted\": false,\n \"id\": \"MwCD66y5xuk-FZi2jI3Lv\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0.3750759105656405,\n \"x\": 594.1343338883066,\n \"y\": -517.957890798986,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 225.10000610351562,\n \"height\": 35,\n \"seed\": 1776873407,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713650936311,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 28,\n \"fontFamily\": 1,\n \"text\": \"Download Blocks\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Download Blocks\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"text\",\n \"version\": 129,\n \"versionNonce\": 1685017329,\n \"index\": \"b0x\",\n \"isDeleted\": false,\n \"id\": \"MwwyDYIb8J2vxAhARjAfK\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1464.1843369400644,\n \"y\": -603.457890798986,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 212.53334045410156,\n \"height\": 35,\n \"seed\": 467071089,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713650584891,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 28,\n \"fontFamily\": 1,\n \"text\": \"Validate Blocks\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Validate Blocks\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"text\",\n \"version\": 80,\n \"versionNonce\": 292376997,\n \"index\": \"b0y\",\n \"isDeleted\": false,\n \"id\": \"ltjV-GtyZj6wSrW53jVON\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0.014588686251640226,\n \"x\": 723.1343338883066,\n \"y\": -841.957890798986,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 214.39999389648438,\n \"height\": 35,\n \"seed\": 1097126687,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713692138954,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 28,\n \"fontFamily\": 1,\n \"text\": \"Final Processing\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Final Processing\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"arrow\",\n \"version\": 1730,\n \"versionNonce\": 955259813,\n \"index\": \"b0z\",\n \"isDeleted\": false,\n \"id\": \"cgedGQ2MpgS37v5sDsFEt\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1212.2747977638235,\n \"y\": -1487.8204535313052,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#ffffff\",\n \"width\": 68.1047679762653,\n \"height\": 172.48396727365844,\n \"seed\": 582052945,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1713692611339,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"-_n9K0bgJ-oFtpjnnaeuP\",\n \"focus\": 0.4251218855390667,\n \"gap\": 8.999999999999886\n },\n \"endBinding\": {\n \"elementId\": \"RumOeXmWSLBfwsZcLG0Ib\",\n \"focus\": -0.3904663240644056,\n \"gap\": 20.196710803833298\n },\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -68.1047679762653,\n -172.48396727365844\n ]\n ]\n },\n {\n \"type\": \"arrow\",\n \"version\": 1345,\n \"versionNonce\": 820658629,\n \"index\": \"b11\",\n \"isDeleted\": false,\n \"id\": \"oyy3j29cSLay83iHEhw17\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 771.7367265177032,\n \"y\": -1235.2829268740225,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#ffffff\",\n \"width\": 156.76530348616222,\n \"height\": 299.9917027417025,\n \"seed\": 1317300843,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1713692308841,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"-_n9K0bgJ-oFtpjnnaeuP\",\n \"focus\": 0.7345692559141487,\n \"gap\": 1\n },\n \"endBinding\": {\n \"elementId\": \"-_n9K0bgJ-oFtpjnnaeuP\",\n \"focus\": 0.4193337056596973,\n \"gap\": 11.503852878965404\n },\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -84.60239262939638,\n 299.9917027417025\n ],\n [\n 72.16291085676585,\n 10.503852878965517\n ]\n ]\n },\n {\n \"type\": \"arrow\",\n \"version\": 81,\n \"versionNonce\": 1983796357,\n \"index\": \"b18\",\n \"isDeleted\": false,\n \"id\": \"7USdFW4_bZpzRgVlW3g8j\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1267.1343338883066,\n \"y\": -1223.29122413232,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 276,\n \"height\": 384,\n \"seed\": 948885669,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1713692308842,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"-_n9K0bgJ-oFtpjnnaeuP\",\n \"focus\": -0.6299497326702104,\n \"gap\": 12.991702741702397\n },\n \"endBinding\": {\n \"elementId\": \"siyDzSseEQqfwuq3Ld5-8\",\n \"focus\": -0.4475117254786141,\n \"gap\": 13.283705940498407\n },\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -276,\n 326\n ],\n [\n -136,\n 384\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 127,\n \"versionNonce\": 727608009,\n \"index\": \"b1B\",\n \"isDeleted\": false,\n \"id\": \"ZtuzO0ddCKNPrObfKzVca\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 485.13433388830686,\n \"y\": -1177.29122413232,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 196.9499969482422,\n \"height\": 140,\n \"seed\": 1622024997,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713712689229,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 28,\n \"fontFamily\": 1,\n \"text\": \"Sync Initiation\\n & \\nBlock Builders\\nPipeline\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Sync Initiation\\n & \\nBlock Builders\\nPipeline\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"arrow\",\n \"version\": 154,\n \"versionNonce\": 1002655819,\n \"index\": \"b1C\",\n \"isDeleted\": false,\n \"id\": \"UP-MOsA8gwhg1R_pdOqQA\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 911.1343338883066,\n \"y\": -1487.2912241323197,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 87.43738091820296,\n \"height\": 182.00000000000045,\n \"seed\": 736519877,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1713692590802,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": {\n \"elementId\": \"RumOeXmWSLBfwsZcLG0Ib\",\n \"focus\": 0.482805404147413,\n \"gap\": 11.20990747647727\n },\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -87.43738091820296,\n -182.00000000000045\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 207,\n \"versionNonce\": 61376811,\n \"index\": \"b1E\",\n \"isDeleted\": false,\n \"id\": \"979O85XGuyY8U87oKtYTr\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1254.5593369400644,\n \"y\": -1106.29122413232,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 423.23333740234375,\n \"height\": 70,\n \"seed\": 2097322763,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713692381322,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 28,\n \"fontFamily\": 1,\n \"text\": \"Payload Validation & Insertion\\nPipeline\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Payload Validation & Insertion\\nPipeline\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 887,\n \"versionNonce\": 810118805,\n \"index\": \"b1EG\",\n \"isDeleted\": false,\n \"id\": \"kJJXsoaK9sX0k2hPaWZv4\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -52.98895085019234,\n \"y\": -598.9944091704378,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#ffffff\",\n \"width\": 447.3636363636364,\n \"height\": 567.7340067340069,\n \"seed\": 2051138293,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"Idbz_UHlTbbQ8v6rIwdES\"\n }\n ],\n \"updated\": 1714326693225,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 1057,\n \"versionNonce\": 1453904885,\n \"index\": \"b1EV\",\n \"isDeleted\": false,\n \"id\": \"Idbz_UHlTbbQ8v6rIwdES\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 100.76786427986804,\n \"y\": -337.6274058034344,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#ffffff\",\n \"width\": 139.85000610351562,\n \"height\": 45,\n \"seed\": 1179892821,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1714326693225,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 36,\n \"fontFamily\": 1,\n \"text\": \"DevP2P\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"kJJXsoaK9sX0k2hPaWZv4\",\n \"originalText\": \"DevP2P\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 332,\n \"versionNonce\": 558698581,\n \"index\": \"b1F\",\n \"isDeleted\": false,\n \"id\": \"cIKoR1G9S613GqXd_iddk\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -43.825128014765426,\n \"y\": -577.0499828094416,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 415.55555555555554,\n \"height\": 228.88888888888877,\n \"seed\": 1503881653,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [],\n \"updated\": 1714326126200,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 163,\n \"versionNonce\": 839551867,\n \"index\": \"b1J\",\n \"isDeleted\": false,\n \"id\": \"Xzfwj1pJ_WfU_dJNjm-cb\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -16.60290579254348,\n \"y\": -564.272205031664,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 125.69999694824219,\n \"height\": 27.965599010749017,\n \"seed\": 894855957,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1714326126200,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 22.372479208599213,\n \"fontFamily\": 1,\n \"text\": \"Transaport\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Transaport\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 168,\n \"versionNonce\": 844250549,\n \"index\": \"b1K\",\n \"isDeleted\": false,\n \"id\": \"uyMgKnE_vbVXzg2tkWAei\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -11.602905792543368,\n \"y\": -511.494427253886,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 348.888888888889,\n \"height\": 129.99999999999994,\n \"seed\": 434258037,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [],\n \"updated\": 1714326126200,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 120,\n \"versionNonce\": 21062683,\n \"index\": \"b1L\",\n \"isDeleted\": false,\n \"id\": \"0aBjUVYof9x5Z-Tl8uyv9\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 12.285983096345603,\n \"y\": -497.6055383649972,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 50,\n \"height\": 25,\n \"seed\": 487352789,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1714326126200,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 20,\n \"fontFamily\": 1,\n \"text\": \"RLPx\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"RLPx\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 168,\n \"versionNonce\": 957005589,\n \"index\": \"b1M\",\n \"isDeleted\": false,\n \"id\": \"U7Qa_ObzWsWuSktEytoR7\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 90.61931642967886,\n \"y\": -470.383316142775,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 98.88888888888893,\n \"height\": 62.222222222222285,\n \"seed\": 2146068277,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [],\n \"updated\": 1714326126201,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 111,\n \"versionNonce\": 1096034491,\n \"index\": \"b1N\",\n \"isDeleted\": false,\n \"id\": \"J8AVpiu1S8fHQMwJY1nkx\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 119.50820531856778,\n \"y\": -452.04998280944153,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 42.18333435058594,\n \"height\": 25,\n \"seed\": 1155643541,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1714326126201,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 20,\n \"fontFamily\": 1,\n \"text\": \"TCP\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"TCP\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 162,\n \"versionNonce\": 1273762933,\n \"index\": \"b1O\",\n \"isDeleted\": false,\n \"id\": \"LD692x2fJR-knVy5i5PQ4\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 217.28598309634583,\n \"y\": -473.71664947610816,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 78.8888888888888,\n \"height\": 67.7777777777777,\n \"seed\": 94887413,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"6L4K3NIkPF7-fWXr7jmnd\"\n }\n ],\n \"updated\": 1714326126201,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 107,\n \"versionNonce\": 420684277,\n \"index\": \"b1P\",\n \"isDeleted\": false,\n \"id\": \"6L4K3NIkPF7-fWXr7jmnd\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 244.67209414387855,\n \"y\": -452.32776058721936,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 24.116666793823242,\n \"height\": 25,\n \"seed\": 155342677,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1714325858561,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 20,\n \"fontFamily\": 1,\n \"text\": \"IP\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"LD692x2fJR-knVy5i5PQ4\",\n \"originalText\": \"IP\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 443,\n \"versionNonce\": 1206212955,\n \"index\": \"b1Q\",\n \"isDeleted\": false,\n \"id\": \"kFUXF3EEaP_EYfePbjPq4\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -38.408461348098854,\n \"y\": -282.8833161427747,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 415.55555555555554,\n \"height\": 228.88888888888877,\n \"seed\": 436642997,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [],\n \"updated\": 1714326126201,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 297,\n \"versionNonce\": 1525957621,\n \"index\": \"b1R\",\n \"isDeleted\": false,\n \"id\": \"XYTcO10n00Tn821PEUe0x\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -11.18623912587691,\n \"y\": -270.1055383649971,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 102.1500015258789,\n \"height\": 27.965599010749017,\n \"seed\": 463095317,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1714326544482,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 22.372479208599213,\n \"fontFamily\": 1,\n \"text\": \"Discovery\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Discovery\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 493,\n \"versionNonce\": 576760283,\n \"index\": \"b1S\",\n \"isDeleted\": false,\n \"id\": \"wHq0o5OPIYgSCam3Ud3ox\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -6.186239125876796,\n \"y\": -217.32776058721902,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 348.888888888889,\n \"height\": 129.99999999999994,\n \"seed\": 1626520437,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [],\n \"updated\": 1714326667492,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 451,\n \"versionNonce\": 817608021,\n \"index\": \"b1T\",\n \"isDeleted\": false,\n \"id\": \"GHkR-NTc9kCpHyJ4KRGEu\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 17.702649763012232,\n \"y\": -203.43887169833033,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 38.83333206176758,\n \"height\": 25,\n \"seed\": 1112900821,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1714326667492,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 20,\n \"fontFamily\": 1,\n \"text\": \"Wire\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Wire\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 473,\n \"versionNonce\": 302298747,\n \"index\": \"b1U\",\n \"isDeleted\": false,\n \"id\": \"kJ26GQukJfY9NLrg-Cwxl\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 96.03598309634549,\n \"y\": -176.21664947610816,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 98.88888888888893,\n \"height\": 62.222222222222285,\n \"seed\": 1935155765,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [],\n \"updated\": 1714326667492,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 439,\n \"versionNonce\": 111428277,\n \"index\": \"b1V\",\n \"isDeleted\": false,\n \"id\": \"kJjfJZvH9KuDUgkKFa1dW\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 124.9248719852344,\n \"y\": -157.88331614277456,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 43.099998474121094,\n \"height\": 25,\n \"seed\": 417338261,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1714326667492,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 20,\n \"fontFamily\": 1,\n \"text\": \"UDP\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"UDP\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 485,\n \"versionNonce\": 1455304475,\n \"index\": \"b1W\",\n \"isDeleted\": false,\n \"id\": \"KdhTH7IKq0qbRAlPOTcfO\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 222.70264976301235,\n \"y\": -179.5499828094412,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 78.8888888888888,\n \"height\": 67.7777777777777,\n \"seed\": 522377461,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"sQ50L5Av6ekng3OZcrKFU\"\n }\n ],\n \"updated\": 1714326667492,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 543,\n \"versionNonce\": 517219349,\n \"index\": \"b1X\",\n \"isDeleted\": false,\n \"id\": \"sQ50L5Av6ekng3OZcrKFU\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 250.08876081054512,\n \"y\": -158.16109392055233,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 24.116666793823242,\n \"height\": 25,\n \"seed\": 1336275541,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1714326667492,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 20,\n \"fontFamily\": 1,\n \"text\": \"IP\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"KdhTH7IKq0qbRAlPOTcfO\",\n \"originalText\": \"IP\",\n \"lineHeight\": 1.25\n },\n {\n \"id\": \"g1ZfPJFDYRULh-a-l4zq8\",\n \"type\": \"rectangle\",\n \"x\": 206.58221759223278,\n \"y\": -272.46228821834586,\n \"width\": 75.47350817609556,\n \"height\": 44.56582689299915,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b1b\",\n \"roundness\": {\n \"type\": 3\n },\n \"seed\": 921396315,\n \"version\": 149,\n \"versionNonce\": 728245083,\n \"isDeleted\": false,\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"i8arnc2i2DpaUEvL_S7kb\"\n }\n ],\n \"updated\": 1714326722526,\n \"link\": null,\n \"locked\": false\n },\n {\n \"id\": \"i8arnc2i2DpaUEvL_S7kb\",\n \"type\": \"text\",\n \"x\": 223.9939709173411,\n \"y\": -262.67937477184626,\n \"width\": 40.650001525878906,\n \"height\": 25,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b1c\",\n \"roundness\": null,\n \"seed\": 682137653,\n \"version\": 110,\n \"versionNonce\": 1323368443,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1714326722526,\n \"link\": null,\n \"locked\": false,\n \"text\": \"DNS\",\n \"fontSize\": 20,\n \"fontFamily\": 1,\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"g1ZfPJFDYRULh-a-l4zq8\",\n \"originalText\": \"DNS\",\n \"lineHeight\": 1.25\n }\n ],\n \"appState\": {\n \"gridSize\": null,\n \"viewBackgroundColor\": \"#ffffff\"\n },\n \"files\": {}\n}" }, { "path": "docs/images/el-architecture/excalidraw/forkchoice-updated.excalidraw", "content": "{\n \"type\": \"excalidraw\",\n \"version\": 2,\n \"source\": \"https://excalidraw.com\",\n \"elements\": [\n {\n \"type\": \"rectangle\",\n \"version\": 841,\n \"versionNonce\": 1183436061,\n \"index\": \"b4r\",\n \"isDeleted\": false,\n \"id\": \"7xM1UGFN1JivXs0OBz6J9\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 233.04467944245857,\n \"y\": -726.0412241323193,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 633.3333333333322,\n \"height\": 111.70728291316534,\n \"seed\": 1177000363,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"vJmK1fp5vKY50o0cdn7ZT\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"-Je4WYHOse5B0zTspiiOU\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"huqkJN3fbtLAcwIYkDXd7\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"qGi_riOg8PM3RPSKlquqk\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"uWWBuHlYAWJGil5tufuaT\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713888831740,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 407,\n \"versionNonce\": 418790149,\n \"index\": \"b4s\",\n \"isDeleted\": false,\n \"id\": \"GhDvh9ShwIp1VErlGZlXz\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 332.73955739363873,\n \"y\": -686.8057299346399,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 426.9333190917969,\n \"height\": 33.73649459783911,\n \"seed\": 1662262949,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713885158235,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 26.98919567827129,\n \"fontFamily\": 1,\n \"text\": \"Engine API: Fork choice updated\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Engine API: Fork choice updated\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 988,\n \"versionNonce\": 36808133,\n \"index\": \"b4t\",\n \"isDeleted\": false,\n \"id\": \"U0JxI3CJ5fLRkHkd2lJEl\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 240.87801277579138,\n \"y\": -1238.3948655889017,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 580.3333333333322,\n \"height\": 97.70728291316536,\n \"seed\": 1232109125,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"vJmK1fp5vKY50o0cdn7ZT\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"-Je4WYHOse5B0zTspiiOU\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713888505663,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 517,\n \"versionNonce\": 676466597,\n \"index\": \"b4u\",\n \"isDeleted\": false,\n \"id\": \"NeYiRZqTMOacN6lghuvxv\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 394.57289072697154,\n \"y\": -1205.1593713912223,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 218.26666259765625,\n \"height\": 33.73649459783911,\n \"seed\": 1907518885,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713887073608,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 26.98919567827129,\n \"fontFamily\": 1,\n \"text\": \"Consensus Layer\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Consensus Layer\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 279,\n \"versionNonce\": 1682644357,\n \"index\": \"b4v\",\n \"isDeleted\": false,\n \"id\": \"Nj9MVEArlf7mA2uqvx4Lr\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -203.95532055754256,\n \"y\": -953.541224132319,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 237,\n \"height\": 134,\n \"seed\": 51104939,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"DUOTucfeISRJaYlvcKuiV\"\n }\n ],\n \"updated\": 1713885259674,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 266,\n \"versionNonce\": 1853301989,\n \"index\": \"b4w\",\n \"isDeleted\": false,\n \"id\": \"DUOTucfeISRJaYlvcKuiV\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -157.92198773283553,\n \"y\": -921.541224132319,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 144.93333435058594,\n \"height\": 70,\n \"seed\": 2027562405,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713885259674,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 28,\n \"fontFamily\": 1,\n \"text\": \"Payload \\nattributes\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"Nj9MVEArlf7mA2uqvx4Lr\",\n \"originalText\": \"Payload attributes\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 451,\n \"versionNonce\": 1699033349,\n \"index\": \"b4x\",\n \"isDeleted\": false,\n \"id\": \"KolO6ZLGcfbVQIr1HU5uL\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 173.54467944245744,\n \"y\": -1077.0832531178262,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 257,\n \"height\": 287.5420289855073,\n \"seed\": 1381559813,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [],\n \"updated\": 1713885256354,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 194,\n \"versionNonce\": 1296456979,\n \"index\": \"b4z\",\n \"isDeleted\": false,\n \"id\": \"k3_qQpfndFtnHwZY-Ukam\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 188.3055490076748,\n \"y\": -1054.7354270308697,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 234.63333129882812,\n \"height\": 33.52173913043478,\n \"seed\": 618329867,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713888642045,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 26.817391304347826,\n \"fontFamily\": 1,\n \"text\": \"Fork choice state\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Fork choice state\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"text\",\n \"version\": 245,\n \"versionNonce\": 1453846941,\n \"index\": \"b50\",\n \"isDeleted\": false,\n \"id\": \"sEqbmNN_nNy8AcT1iTweF\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 194.2649692975299,\n \"y\": -970.5586154366669,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 200.31666564941406,\n \"height\": 130.3623188405797,\n \"seed\": 1595669483,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713888642045,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 20.85797101449275,\n \"fontFamily\": 1,\n \"text\": \"Head block hash\\n\\nFinalized block hash\\n\\nSafe block hash\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Head block hash\\n\\nFinalized block hash\\n\\nSafe block hash\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"arrow\",\n \"version\": 287,\n \"versionNonce\": 182302053,\n \"index\": \"b51\",\n \"isDeleted\": false,\n \"id\": \"vJmK1fp5vKY50o0cdn7ZT\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 234.04467944245744,\n \"y\": -1180.541224132319,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 150,\n \"height\": 535,\n \"seed\": 1841881707,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"V_UzrDa44DOPjOBrm69im\"\n }\n ],\n \"updated\": 1713888476384,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"U0JxI3CJ5fLRkHkd2lJEl\",\n \"focus\": 0.6855963411673234,\n \"gap\": 6.833333333333883\n },\n \"endBinding\": {\n \"elementId\": \"7xM1UGFN1JivXs0OBz6J9\",\n \"focus\": -0.8809738659579082,\n \"gap\": 8.00000000000108\n },\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -150,\n 65\n ],\n [\n -89,\n 492\n ],\n [\n -9,\n 535\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 9,\n \"versionNonce\": 423737259,\n \"index\": \"b52\",\n \"isDeleted\": false,\n \"id\": \"V_UzrDa44DOPjOBrm69im\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 45.4144442324683,\n \"y\": -911.1726918023876,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 111.81666564941406,\n \"height\": 35,\n \"seed\": 1584860171,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713885243528,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 28,\n \"fontFamily\": 1,\n \"text\": \"Request\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"vJmK1fp5vKY50o0cdn7ZT\",\n \"originalText\": \"Request\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"diamond\",\n \"version\": 62,\n \"versionNonce\": 295026387,\n \"index\": \"b53\",\n \"isDeleted\": false,\n \"id\": \"29B4xiJVviN_LhIJNJ7YK\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 465.54467944245744,\n \"y\": -483.91622413231903,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 265,\n \"height\": 230,\n \"seed\": 1476718501,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"mKc1ypnTmZP8SnKrNPP2T\"\n },\n {\n \"id\": \"7-Qb0KkW2P7uYnXAzDoBX\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"sOEM1ADIYiGnvG9RdXxYZ\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"uWWBuHlYAWJGil5tufuaT\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713888851556,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 36,\n \"versionNonce\": 213675123,\n \"index\": \"b54\",\n \"isDeleted\": false,\n \"id\": \"mKc1ypnTmZP8SnKrNPP2T\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 537.8613450918715,\n \"y\": -403.91622413231903,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 120.86666870117188,\n \"height\": 70,\n \"seed\": 1111790763,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713888851556,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 28,\n \"fontFamily\": 1,\n \"text\": \"Unknown \\nPayload?\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"29B4xiJVviN_LhIJNJ7YK\",\n \"originalText\": \"Unknown Payload?\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 138,\n \"versionNonce\": 2136773931,\n \"index\": \"b55\",\n \"isDeleted\": false,\n \"id\": \"n3S3VovWk4fnKbOuouSI1\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -17.705320557542564,\n \"y\": -417.91622413231903,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 257.5,\n \"height\": 85,\n \"seed\": 68721931,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"afHX7sBp1OUUTclf84scN\"\n },\n {\n \"id\": \"7-Qb0KkW2P7uYnXAzDoBX\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713885596579,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 117,\n \"versionNonce\": 1158068171,\n \"index\": \"b56\",\n \"isDeleted\": false,\n \"id\": \"afHX7sBp1OUUTclf84scN\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 22.278009215406655,\n \"y\": -392.91622413231903,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 177.53334045410156,\n \"height\": 35,\n \"seed\": 1824958699,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713885596579,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 28,\n \"fontFamily\": 1,\n \"text\": \"Initiate Sync\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"n3S3VovWk4fnKbOuouSI1\",\n \"originalText\": \"Initiate Sync\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"arrow\",\n \"version\": 469,\n \"versionNonce\": 1414278067,\n \"index\": \"b57\",\n \"isDeleted\": false,\n \"id\": \"7-Qb0KkW2P7uYnXAzDoBX\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 470.90645650574106,\n \"y\": -362.93848660120324,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 227.36177706328363,\n \"height\": 6.280630762775274,\n \"seed\": 1963192645,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"r5bQcwx5gB_Z68bq1zPMe\"\n }\n ],\n \"updated\": 1713888851557,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"29B4xiJVviN_LhIJNJ7YK\",\n \"focus\": -0.08245405264030108,\n \"gap\": 1\n },\n \"endBinding\": {\n \"elementId\": \"n3S3VovWk4fnKbOuouSI1\",\n \"focus\": 0.055082964274451626,\n \"gap\": 3.75\n },\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -227.36177706328363,\n -6.280630762775274\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 8,\n \"versionNonce\": 555741701,\n \"index\": \"b58\",\n \"isDeleted\": false,\n \"id\": \"r5bQcwx5gB_Z68bq1zPMe\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 335.77139180744064,\n \"y\": -385.59284923563484,\n \"strokeColor\": \"#2f9e44\",\n \"backgroundColor\": \"transparent\",\n \"width\": 44.96666717529297,\n \"height\": 35,\n \"seed\": 510159845,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713885785080,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 28,\n \"fontFamily\": 1,\n \"text\": \"Yes\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"7-Qb0KkW2P7uYnXAzDoBX\",\n \"originalText\": \"Yes\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"diamond\",\n \"version\": 440,\n \"versionNonce\": 677420811,\n \"index\": \"b59\",\n \"isDeleted\": false,\n \"id\": \"W6dTc6uV9Y-CGQcYsBhSv\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 418.54467944245744,\n \"y\": -79.16622413231903,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 361.24999999999994,\n \"height\": 327.5,\n \"seed\": 327681925,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"mB2HR5VQzEprxguNKo4aq\"\n },\n {\n \"id\": \"sOEM1ADIYiGnvG9RdXxYZ\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"KC6QK9dq3d7hBlVK5CtpY\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"UQ1zD42iTq8WrU7LEQPPk\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713886306155,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 499,\n \"versionNonce\": 1353846507,\n \"index\": \"b5A\",\n \"isDeleted\": false,\n \"id\": \"mB2HR5VQzEprxguNKo4aq\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 513.8571794424574,\n \"y\": 32.20877586768097,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 171,\n \"height\": 105,\n \"seed\": 981913317,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713885761000,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 28,\n \"fontFamily\": 1,\n \"text\": \"Head block \\nhash a valid\\nancestor?\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"W6dTc6uV9Y-CGQcYsBhSv\",\n \"originalText\": \"Head block hash a valid ancestor?\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"arrow\",\n \"version\": 198,\n \"versionNonce\": 937761523,\n \"index\": \"b5E\",\n \"isDeleted\": false,\n \"id\": \"sOEM1ADIYiGnvG9RdXxYZ\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 593.2648008139549,\n \"y\": -247.2036191883442,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 1.7607063411123818,\n \"height\": 170.44462624932652,\n \"seed\": 1160137195,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"FhDToE7skv_CXFONiKFvD\"\n }\n ],\n \"updated\": 1713888851558,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"29B4xiJVviN_LhIJNJ7YK\",\n \"focus\": 0.0424956608214578,\n \"gap\": 8.240528189205534\n },\n \"endBinding\": {\n \"elementId\": \"W6dTc6uV9Y-CGQcYsBhSv\",\n \"focus\": -0.013716201227202653,\n \"gap\": 1\n },\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 1.7607063411123818,\n 170.44462624932652\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 16,\n \"versionNonce\": 1590965227,\n \"index\": \"b5F\",\n \"isDeleted\": false,\n \"id\": \"FhDToE7skv_CXFONiKFvD\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 503.66967944245744,\n \"y\": -214.16622413231903,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 182.25,\n \"height\": 35,\n \"seed\": 1431791915,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713885763743,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 28,\n \"fontFamily\": 1,\n \"text\": \"Either yes/no\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"sOEM1ADIYiGnvG9RdXxYZ\",\n \"originalText\": \"Either yes/no\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"arrow\",\n \"version\": 534,\n \"versionNonce\": 998854155,\n \"index\": \"b5G\",\n \"isDeleted\": false,\n \"id\": \"KC6QK9dq3d7hBlVK5CtpY\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 780.6003318042849,\n \"y\": 83.99138725209008,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 356.11101430483905,\n \"height\": 7.50353660331308,\n \"seed\": 1360356875,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"oYoitbkQ5mDKuggg45vVf\"\n }\n ],\n \"updated\": 1713888638017,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"W6dTc6uV9Y-CGQcYsBhSv\",\n \"gap\": 1,\n \"focus\": -0.026922028353326067\n },\n \"endBinding\": {\n \"elementId\": \"dGHHPsplaHTpT-MoKae73\",\n \"gap\": 1,\n \"focus\": -0.221052895966243\n },\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 356.11101430483905,\n 7.50353660331308\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 6,\n \"versionNonce\": 660885733,\n \"index\": \"b5H\",\n \"isDeleted\": false,\n \"id\": \"oYoitbkQ5mDKuggg45vVf\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 929.811345854811,\n \"y\": 66.45877586768097,\n \"strokeColor\": \"#2f9e44\",\n \"backgroundColor\": \"transparent\",\n \"width\": 44.96666717529297,\n \"height\": 35,\n \"seed\": 1295896741,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713885810835,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 28,\n \"fontFamily\": 1,\n \"text\": \"Yes\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"KC6QK9dq3d7hBlVK5CtpY\",\n \"originalText\": \"Yes\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 339,\n \"versionNonce\": 520187723,\n \"index\": \"b5I\",\n \"isDeleted\": false,\n \"id\": \"O1Jx6ynsuhFUb1_i4aZNc\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1198.5008197933344,\n \"y\": -309.22104869372254,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 339.6491228070176,\n \"height\": 545.1754385964912,\n \"seed\": 1286970667,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [],\n \"updated\": 1713886225509,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 114,\n \"versionNonce\": 1027556019,\n \"index\": \"b5J\",\n \"isDeleted\": false,\n \"id\": \"bRX3Lk7EW_vE7XY96o-NZ\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1215.5476034190656,\n \"y\": -283.16841711477514,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 218.56666564941406,\n \"height\": 34.73684210526316,\n \"seed\": 498864491,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713888642045,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 27.789473684210524,\n \"fontFamily\": 1,\n \"text\": \"Payload Status\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Payload Status\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 138,\n \"versionNonce\": 1545623691,\n \"index\": \"b5K\",\n \"isDeleted\": false,\n \"id\": \"bw_LJvtB-JLAdKsjS4OJx\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1231.307837337194,\n \"y\": -201.15087325512604,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 278.12177502579976,\n \"height\": 96.49122807017544,\n \"seed\": 466500843,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [],\n \"updated\": 1713886225509,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 117,\n \"versionNonce\": 726775293,\n \"index\": \"b5L\",\n \"isDeleted\": false,\n \"id\": \"ZC0tJHlhJDdmBGAko40Di\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1245.4977238181023,\n \"y\": -186.9609867742179,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 74.48332977294922,\n \"height\": 26.487788097695216,\n \"seed\": 870131819,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713888642046,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 21.190230478156174,\n \"fontFamily\": 1,\n \"text\": \"Status\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Status\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"text\",\n \"version\": 199,\n \"versionNonce\": 877294675,\n \"index\": \"b5M\",\n \"isDeleted\": false,\n \"id\": \"rDjTssuIeH2tGE6BTFYHB\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1346.0567193461382,\n \"y\": -143.4642547480741,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 65.5999984741211,\n \"height\": 26.487788097695216,\n \"seed\": 1881386667,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713888642046,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 21.190230478156174,\n \"fontFamily\": 1,\n \"text\": \"VALID\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"VALID\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 228,\n \"versionNonce\": 345735275,\n \"index\": \"b5O\",\n \"isDeleted\": false,\n \"id\": \"e8oxR6LS8CcGVCAeE2FdM\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1223.475019999733,\n \"y\": -66.06315395688046,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 278.12177502579976,\n \"height\": 134.12280701754386,\n \"seed\": 1391497381,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [],\n \"updated\": 1713886225509,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 188,\n \"versionNonce\": 1661202013,\n \"index\": \"b5P\",\n \"isDeleted\": false,\n \"id\": \"DJ-PGwpyhF9QcYE1beg5S\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1249.2438538490624,\n \"y\": -51.873267475972284,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 189.06666564941406,\n \"height\": 26.487788097695216,\n \"seed\": 1245787141,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713888642046,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 21.190230478156174,\n \"fontFamily\": 1,\n \"text\": \"Latest valid hash\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Latest valid hash\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"text\",\n \"version\": 377,\n \"versionNonce\": 842953203,\n \"index\": \"b5Q\",\n \"isDeleted\": false,\n \"id\": \"s9jOs4Pp2EjLVSKu1l-ec\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1252.3467090262209,\n \"y\": -9.871203492484199,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 217.4166717529297,\n \"height\": 54.03508771929825,\n \"seed\": 174484325,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713888642046,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 21.614035087719298,\n \"fontFamily\": 1,\n \"text\": \"Fork choice state's \\n Head block hash\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Fork choice state's \\n Head block hash\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 581,\n \"versionNonce\": 1329677597,\n \"index\": \"b5R\",\n \"isDeleted\": false,\n \"id\": \"dGHHPsplaHTpT-MoKae73\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1137.711346109124,\n \"y\": -408.12455746565234,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 440,\n \"height\": 824.2909356725146,\n \"seed\": 2115798219,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"KC6QK9dq3d7hBlVK5CtpY\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"huqkJN3fbtLAcwIYkDXd7\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713888667461,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 246,\n \"versionNonce\": 1821383357,\n \"index\": \"b5S\",\n \"isDeleted\": false,\n \"id\": \"hGOJ0OTZE_V3i1sUE_9oB\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1177.33853909158,\n \"y\": -394.74736448319624,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 157.4166717529297,\n \"height\": 44.99999999999999,\n \"seed\": 828879723,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713888642046,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 35.99999999999999,\n \"fontFamily\": 1,\n \"text\": \"Response\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Response\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 193,\n \"versionNonce\": 1257191115,\n \"index\": \"b5T\",\n \"isDeleted\": false,\n \"id\": \"dOpVtgtoMyIW8E8e6k792\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1225.0832071342354,\n \"y\": 103.60058873317803,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 278.12177502579976,\n \"height\": 96.49122807017544,\n \"seed\": 902681867,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [],\n \"updated\": 1713886225510,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 188,\n \"versionNonce\": 2015476627,\n \"index\": \"b5U\",\n \"isDeleted\": false,\n \"id\": \"pa8b4xCLkiK7TAwhxsc_T\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1240.559643322746,\n \"y\": 117.79047521408614,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 160.96665954589844,\n \"height\": 26.487788097695212,\n \"seed\": 1057291179,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713888642046,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 21.19023047815617,\n \"fontFamily\": 1,\n \"text\": \"Validation error\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Validation error\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"text\",\n \"version\": 252,\n \"versionNonce\": 1620556573,\n \"index\": \"b5V\",\n \"isDeleted\": false,\n \"id\": \"e2DOvjlvCuZz6xQXiZna-\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1341.1186388507817,\n \"y\": 161.28720724022998,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 33.06666564941406,\n \"height\": 26.487788097695216,\n \"seed\": 1876840011,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713888642046,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 21.190230478156174,\n \"fontFamily\": 1,\n \"text\": \"null\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"null\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 251,\n \"versionNonce\": 2001995435,\n \"index\": \"b5W\",\n \"isDeleted\": false,\n \"id\": \"RyXhfB79cfeuoZHprL-GH\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1230.229405964645,\n \"y\": 278.5713489670963,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 278.12177502579976,\n \"height\": 96.49122807017544,\n \"seed\": 1770401189,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [],\n \"updated\": 1713886225510,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 256,\n \"versionNonce\": 1646973235,\n \"index\": \"b5X\",\n \"isDeleted\": false,\n \"id\": \"zX7Sscb8XZWa0D9EElslp\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1245.7058421531556,\n \"y\": 292.76123544800447,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 115.75,\n \"height\": 26.487788097695216,\n \"seed\": 370880773,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713888642046,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 21.190230478156174,\n \"fontFamily\": 1,\n \"text\": \"Payload Id\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Payload Id\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"text\",\n \"version\": 310,\n \"versionNonce\": 1200377725,\n \"index\": \"b5Y\",\n \"isDeleted\": false,\n \"id\": \"-2UsVoJFXT8hWyR_0EAMa\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1346.2648376811915,\n \"y\": 336.2579674741482,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 33.06666564941406,\n \"height\": 26.487788097695216,\n \"seed\": 603506789,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713888642046,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 21.190230478156174,\n \"fontFamily\": 1,\n \"text\": \"null\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"null\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"diamond\",\n \"version\": 665,\n \"versionNonce\": 1236443083,\n \"index\": \"b5Z\",\n \"isDeleted\": false,\n \"id\": \"aKSIn9htzpM8ba05Pwoyb\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 348.848250871029,\n \"y\": 558.8516330105381,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 508.3928571428571,\n \"height\": 440,\n \"seed\": 971588875,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"GoFe_X8GFWXBC30iHyhLr\"\n },\n {\n \"id\": \"UQ1zD42iTq8WrU7LEQPPk\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"lGlTvKdqStL96LWLUe2mO\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713887093234,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 764,\n \"versionNonce\": 1828081739,\n \"index\": \"b5a\",\n \"isDeleted\": false,\n \"id\": \"GoFe_X8GFWXBC30iHyhLr\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 486.89646210498546,\n \"y\": 673.8516330105381,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 232.10000610351562,\n \"height\": 210,\n \"seed\": 238185387,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713886631293,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 28,\n \"fontFamily\": 1,\n \"text\": \"The payload \\nreferenced by \\nhead block hash \\n passes \\npayload \\nvalidation?\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"aKSIn9htzpM8ba05Pwoyb\",\n \"originalText\": \"The payload referenced by head block hash passes \\npayload validation?\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"arrow\",\n \"version\": 320,\n \"versionNonce\": 1890208933,\n \"index\": \"b5b\",\n \"isDeleted\": false,\n \"id\": \"UQ1zD42iTq8WrU7LEQPPk\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 596.8354441628132,\n \"y\": 247.56738722119417,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 6.872923261254982,\n \"height\": 310.53623625526996,\n \"seed\": 376449899,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"Pz5aUZ-uOA-RddMo3rQA9\"\n }\n ],\n \"updated\": 1713886591114,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"W6dTc6uV9Y-CGQcYsBhSv\",\n \"gap\": 1,\n \"focus\": 0.03301213262669178\n },\n \"endBinding\": {\n \"elementId\": \"aKSIn9htzpM8ba05Pwoyb\",\n \"gap\": 1,\n \"focus\": 0.024878454732600416\n },\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 6.872923261254982,\n 310.53623625526996\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 5,\n \"versionNonce\": 1464576389,\n \"index\": \"b5c\",\n \"isDeleted\": false,\n \"id\": \"Pz5aUZ-uOA-RddMo3rQA9\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 583.8613469992201,\n \"y\": 377.95877586768097,\n \"strokeColor\": \"#e03131\",\n \"backgroundColor\": \"transparent\",\n \"width\": 38.36666488647461,\n \"height\": 35,\n \"seed\": 138916005,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713886310301,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 28,\n \"fontFamily\": 1,\n \"text\": \"NO\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"UQ1zD42iTq8WrU7LEQPPk\",\n \"originalText\": \"NO\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"diamond\",\n \"version\": 776,\n \"versionNonce\": 1079273189,\n \"index\": \"b5d\",\n \"isDeleted\": false,\n \"id\": \"hvWTesNfWB2bnqZdoozhy\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 347.2450762678542,\n \"y\": 1193.8397282486328,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 508.3928571428571,\n \"height\": 440,\n \"seed\": 623975429,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"ndIp2emW_DL2ea30lrolJ\"\n },\n {\n \"id\": \"tELrAaGLNswO3G2pf8AXj\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"lGlTvKdqStL96LWLUe2mO\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"57Hi0kF-HPHt7c0b3oaXQ\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713887683738,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 888,\n \"versionNonce\": 634353477,\n \"index\": \"b5e\",\n \"isDeleted\": false,\n \"id\": \"ndIp2emW_DL2ea30lrolJ\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 498.81828902768956,\n \"y\": 1308.8397282486328,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 205.0500030517578,\n \"height\": 210,\n \"seed\": 1327059813,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713887340499,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 28,\n \"fontFamily\": 1,\n \"text\": \"The payload \\nreferenced by \\nfinalized block \\nhash passes \\npayload \\nvalidation?\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"hvWTesNfWB2bnqZdoozhy\",\n \"originalText\": \"The payload referenced by finalized block hash passes \\npayload validation?\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"arrow\",\n \"version\": 90,\n \"versionNonce\": 1484007941,\n \"index\": \"b5f\",\n \"isDeleted\": false,\n \"id\": \"tELrAaGLNswO3G2pf8AXj\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 347.0224730868647,\n \"y\": 1410.9057857359985,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 370.977793644407,\n \"height\": 0.3415587648169094,\n \"seed\": 185869259,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"ehNH1sFr1daQ9wPnkJljH\"\n }\n ],\n \"updated\": 1713887340503,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"hvWTesNfWB2bnqZdoozhy\",\n \"focus\": 0.01505994005994007,\n \"gap\": 2.364133843240154\n },\n \"endBinding\": {\n \"elementId\": \"9-YbwXdLKXvJwWOQ5JZUa\",\n \"focus\": -0.11333288449022563,\n \"gap\": 15.71428571428595\n },\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -370.977793644407,\n -0.3415587648169094\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 8,\n \"versionNonce\": 1736446725,\n \"index\": \"b5g\",\n \"isDeleted\": false,\n \"id\": \"ehNH1sFr1daQ9wPnkJljH\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 135.70420299766826,\n \"y\": 1398.244490153395,\n \"strokeColor\": \"#2f9e44\",\n \"backgroundColor\": \"transparent\",\n \"width\": 44.96666717529297,\n \"height\": 35,\n \"seed\": 1222660203,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713886830165,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 28,\n \"fontFamily\": 1,\n \"text\": \"Yes\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"tELrAaGLNswO3G2pf8AXj\",\n \"originalText\": \"Yes\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 83,\n \"versionNonce\": 1067408107,\n \"index\": \"b5h\",\n \"isDeleted\": false,\n \"id\": \"9-YbwXdLKXvJwWOQ5JZUa\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -693.9553205575426,\n \"y\": 1194.3159187248234,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 654.2857142857142,\n \"height\": 487.1428571428574,\n \"seed\": 595053451,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"tELrAaGLNswO3G2pf8AXj\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713887027394,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 95,\n \"versionNonce\": 1659070021,\n \"index\": \"b5i\",\n \"isDeleted\": false,\n \"id\": \"DfiLQuvgmwQLWgnBnpDY6\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -669.0981777003998,\n \"y\": 1228.6016330105376,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 504.5333251953125,\n \"height\": 35,\n \"seed\": 271210373,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713887161645,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 28,\n \"fontFamily\": 1,\n \"text\": \"Update fork choice state atomically\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Update fork choice state atomically\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"text\",\n \"version\": 130,\n \"versionNonce\": 1937689675,\n \"index\": \"b5j\",\n \"isDeleted\": false,\n \"id\": \"YXq3abc7_wVsFBZvW8S81\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -663.9553205575427,\n \"y\": 1334.3159187248234,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 577.9166870117188,\n \"height\": 70,\n \"seed\": 450866693,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713886984652,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 28,\n \"fontFamily\": 1,\n \"text\": \"1. Set head of canonical chain to\\n thr block referenced by head block hash \",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"1. Set head of canonical chain to\\n thr block referenced by head block hash \",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"text\",\n \"version\": 243,\n \"versionNonce\": 1507533995,\n \"index\": \"b5k\",\n \"isDeleted\": false,\n \"id\": \"IbXQQZ9AhXy2j1JSN1sQu\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -670.0565212062593,\n \"y\": 1455.0302044391096,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 626.4166870117188,\n \"height\": 70,\n \"seed\": 749368715,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713887023078,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 28,\n \"fontFamily\": 1,\n \"text\": \"2. Set the most recent finalized block to\\n thr block referenced by finalized block hash \",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"2. Set the most recent finalized block to\\n thr block referenced by finalized block hash \",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"arrow\",\n \"version\": 87,\n \"versionNonce\": 1041968325,\n \"index\": \"b5l\",\n \"isDeleted\": false,\n \"id\": \"lGlTvKdqStL96LWLUe2mO\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 604.894680548156,\n \"y\": 998.5730217768092,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 4.944338181776629,\n \"height\": 195.23475276308443,\n \"seed\": 1841683051,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"3RwsHQu_aPf3Oc-bRiMxq\"\n }\n ],\n \"updated\": 1713887340505,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"aKSIn9htzpM8ba05Pwoyb\",\n \"focus\": -0.031288295671855836,\n \"gap\": 1\n },\n \"endBinding\": {\n \"elementId\": \"hvWTesNfWB2bnqZdoozhy\",\n \"focus\": -0.027787534636850485,\n \"gap\": 1\n },\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -4.944338181776629,\n 195.23475276308443\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 6,\n \"versionNonce\": 1157784645,\n \"index\": \"b5m\",\n \"isDeleted\": false,\n \"id\": \"3RwsHQu_aPf3Oc-bRiMxq\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 579.7042029976678,\n \"y\": 1078.5302044391092,\n \"strokeColor\": \"#2f9e44\",\n \"backgroundColor\": \"transparent\",\n \"width\": 44.96666717529297,\n \"height\": 35,\n \"seed\": 2056252421,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713887108945,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 28,\n \"fontFamily\": 1,\n \"text\": \"Yes\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"lGlTvKdqStL96LWLUe2mO\",\n \"originalText\": \"Yes\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"diamond\",\n \"version\": 1087,\n \"versionNonce\": 1120973707,\n \"index\": \"b5n\",\n \"isDeleted\": false,\n \"id\": \"fDdJaoU64671xFPa9MwhA\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 306.10221912499674,\n \"y\": 1788.919093327998,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 591.7261904761906,\n \"height\": 510,\n \"seed\": 125858923,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"JZfe9eFUBU8q8S7s47S1Q\"\n },\n {\n \"id\": \"eAJX2Hyq21XewGNx6Zk2E\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"57Hi0kF-HPHt7c0b3oaXQ\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"7afFcGJd2KpSWEavfvfXN\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713888131153,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 1269,\n \"versionNonce\": 1517474283,\n \"index\": \"b5o\",\n \"isDeleted\": false,\n \"id\": \"JZfe9eFUBU8q8S7s47S1Q\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 463.22543239345845,\n \"y\": 1921.419093327998,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 277.6166687011719,\n \"height\": 245,\n \"seed\": 871149323,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713888092606,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 28,\n \"fontFamily\": 1,\n \"text\": \"Does the payload \\nreferenced by \\nfinalized or safe \\nblock\\nbelong to the chain \\nreferenced by head \\nblock hash ?\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"fDdJaoU64671xFPa9MwhA\",\n \"originalText\": \"Does the payload referenced by finalized or safe block\\nbelong to the chain referenced by head block hash ?\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 81,\n \"versionNonce\": 1580787261,\n \"index\": \"b5q\",\n \"isDeleted\": false,\n \"id\": \"K5OOc7V_1CdFK0I-TGGFw\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1293.1875365853143,\n \"y\": 1930.0302044391096,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 492.0681265206816,\n \"height\": 210.66666666666697,\n \"seed\": 1120718437,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"eAJX2Hyq21XewGNx6Zk2E\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"qGi_riOg8PM3RPSKlquqk\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713888684189,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 79,\n \"versionNonce\": 29373139,\n \"index\": \"b5r\",\n \"isDeleted\": false,\n \"id\": \"n0YsEGGgpXQ188f8QNwl5\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1336.2434976558739,\n \"y\": 1953.8647543174552,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 89.68333435058594,\n \"height\": 44.52018061320226,\n \"seed\": 1522563333,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713888642046,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 35.61614449056181,\n \"fontFamily\": 1,\n \"text\": \"Error\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Error\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"text\",\n \"version\": 72,\n \"versionNonce\": 531584989,\n \"index\": \"b5t\",\n \"isDeleted\": false,\n \"id\": \"fWkKg5mjt90S-q12c4EF4\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1370.0731813541709,\n \"y\": 2049.971810278526,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 329.8833312988281,\n \"height\": 34.59854014598545,\n \"seed\": 1356563109,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713888642046,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 27.67883211678836,\n \"fontFamily\": 1,\n \"text\": \"Invalid forkchoice state\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Invalid forkchoice state\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"arrow\",\n \"version\": 163,\n \"versionNonce\": 996328869,\n \"index\": \"b5u\",\n \"isDeleted\": false,\n \"id\": \"eAJX2Hyq21XewGNx6Zk2E\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 896.487587832416,\n \"y\": 2041.4432900790293,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 387.9499487528983,\n \"height\": 8.31990967790398,\n \"seed\": 509661195,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"oZDpsHAUZn1btAAcZaaCq\"\n }\n ],\n \"updated\": 1713888092616,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"fDdJaoU64671xFPa9MwhA\",\n \"gap\": 1,\n \"focus\": 0.014733115468412163\n },\n \"endBinding\": {\n \"elementId\": \"K5OOc7V_1CdFK0I-TGGFw\",\n \"gap\": 8.75,\n \"focus\": 0.06965221910874085\n },\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 387.9499487528983,\n -8.31990967790398\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 5,\n \"versionNonce\": 1347021899,\n \"index\": \"b5v\",\n \"isDeleted\": false,\n \"id\": \"oZDpsHAUZn1btAAcZaaCq\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1062.2792037606073,\n \"y\": 2029.7802044391096,\n \"strokeColor\": \"#e03131\",\n \"backgroundColor\": \"transparent\",\n \"width\": 49.31666564941406,\n \"height\": 45,\n \"seed\": 1575143211,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713887656198,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 36,\n \"fontFamily\": 1,\n \"text\": \"NO\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"eAJX2Hyq21XewGNx6Zk2E\",\n \"originalText\": \"NO\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"arrow\",\n \"version\": 151,\n \"versionNonce\": 1771004005,\n \"index\": \"b5x\",\n \"isDeleted\": false,\n \"id\": \"57Hi0kF-HPHt7c0b3oaXQ\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 603.1875365853143,\n \"y\": 1633.6510996289605,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 0,\n \"height\": 155.0012399335044,\n \"seed\": 644564485,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"BvjWVS8cSIjKydLe2p0uf\"\n }\n ],\n \"updated\": 1713888092618,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"hvWTesNfWB2bnqZdoozhy\",\n \"focus\": -0.006868828786636338,\n \"gap\": 1\n },\n \"endBinding\": {\n \"elementId\": \"fDdJaoU64671xFPa9MwhA\",\n \"focus\": 0.004131039801495703,\n \"gap\": 1\n },\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 0,\n 155.0012399335044\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 11,\n \"versionNonce\": 110646437,\n \"index\": \"b5xV\",\n \"isDeleted\": false,\n \"id\": \"BvjWVS8cSIjKydLe2p0uf\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 580.7042029976678,\n \"y\": 1700.4052044391096,\n \"strokeColor\": \"#2f9e44\",\n \"backgroundColor\": \"transparent\",\n \"width\": 44.96666717529297,\n \"height\": 35,\n \"seed\": 1824106725,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713887764209,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 28,\n \"fontFamily\": 1,\n \"text\": \"Yes\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"57Hi0kF-HPHt7c0b3oaXQ\",\n \"originalText\": \"Yes\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"diamond\",\n \"version\": 1266,\n \"versionNonce\": 759008011,\n \"index\": \"b5z\",\n \"isDeleted\": false,\n \"id\": \"BfCwSE7YpA3RGF2-igdRn\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 271.49110801388576,\n \"y\": 2536.0302044391096,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 641.7261904761906,\n \"height\": 580,\n \"seed\": 1465776165,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"3st3o3yBkCPu1v0fXwBUa\"\n },\n {\n \"id\": \"P21MJLoBr_wmtBmlPYj9Z\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"7afFcGJd2KpSWEavfvfXN\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"GfFYhOO7nkdzj__kv-Xp2\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713888565856,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 1555,\n \"versionNonce\": 123066885,\n \"index\": \"b60\",\n \"isDeleted\": false,\n \"id\": \"3st3o3yBkCPu1v0fXwBUa\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 456.3726525811756,\n \"y\": 2686.0302044391096,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 272.1000061035156,\n \"height\": 280,\n \"seed\": 999664517,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713888081461,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 28,\n \"fontFamily\": 1,\n \"text\": \"\\nIs the payload \\nattributes\\n timestamp \\n> \\ntimestamp of block \\nreferenced by\\nhead block hash?\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"BfCwSE7YpA3RGF2-igdRn\",\n \"originalText\": \"\\nIs the payload attributes\\n timestamp \\n> \\ntimestamp of block referenced by\\nhead block hash?\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 209,\n \"versionNonce\": 460896093,\n \"index\": \"b61\",\n \"isDeleted\": false,\n \"id\": \"wk0Rw2YteS3p5_V33a08d\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1304.6534733249732,\n \"y\": 2734.0302044391096,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 492.0681265206816,\n \"height\": 210.66666666666697,\n \"seed\": 909395659,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"P21MJLoBr_wmtBmlPYj9Z\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"q5UbeysotrMmQ8Efoacdh\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713888708317,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 206,\n \"versionNonce\": 2004377715,\n \"index\": \"b62\",\n \"isDeleted\": false,\n \"id\": \"EtX2i1Q-4Z-tqpdzVwVP4\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1347.7094343955328,\n \"y\": 2757.864754317455,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 89.68333435058594,\n \"height\": 44.52018061320226,\n \"seed\": 1429681515,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713888642046,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 35.61614449056181,\n \"fontFamily\": 1,\n \"text\": \"Error\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Error\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"text\",\n \"version\": 240,\n \"versionNonce\": 105549381,\n \"index\": \"b63\",\n \"isDeleted\": false,\n \"id\": \"hI0nQsINFzDByxNGZ87Rd\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1381.53911809383,\n \"y\": 2853.971810278526,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 363,\n \"height\": 34.59854014598545,\n \"seed\": 2133020683,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713888117616,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 27.67883211678836,\n \"fontFamily\": 1,\n \"text\": \"Invalid payload attributes\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Invalid payload attributes\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"arrow\",\n \"version\": 341,\n \"versionNonce\": 1199124069,\n \"index\": \"b65\",\n \"isDeleted\": false,\n \"id\": \"P21MJLoBr_wmtBmlPYj9Z\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 898.3084040476151,\n \"y\": 2830.886821379966,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 399.04579920436595,\n \"height\": 7.186562621105622,\n \"seed\": 756004523,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"rElwDGbiV5ImQI9jiilLI\"\n }\n ],\n \"updated\": 1713888122951,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"BfCwSE7YpA3RGF2-igdRn\",\n \"focus\": -0.002253189078534226,\n \"gap\": 1\n },\n \"endBinding\": {\n \"elementId\": \"wk0Rw2YteS3p5_V33a08d\",\n \"focus\": -0.02981134021483749,\n \"gap\": 7.299270072992044\n },\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 399.04579920436595,\n 7.186562621105622\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 5,\n \"versionNonce\": 2024215205,\n \"index\": \"b65V\",\n \"isDeleted\": false,\n \"id\": \"rElwDGbiV5ImQI9jiilLI\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1103.1708708087435,\n \"y\": 2673.5302044391096,\n \"strokeColor\": \"#e03131\",\n \"backgroundColor\": \"transparent\",\n \"width\": 38.36666488647461,\n \"height\": 35,\n \"seed\": 1072254405,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713888073413,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 28,\n \"fontFamily\": 1,\n \"text\": \"NO\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"P21MJLoBr_wmtBmlPYj9Z\",\n \"originalText\": \"NO\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"arrow\",\n \"version\": 97,\n \"versionNonce\": 425491557,\n \"index\": \"b68\",\n \"isDeleted\": false,\n \"id\": \"7afFcGJd2KpSWEavfvfXN\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 590.6875365853143,\n \"y\": 2281.0302044391096,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 5,\n \"height\": 260,\n \"seed\": 147064773,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"AGohpqt6XpxMC-GpX7G9v\"\n }\n ],\n \"updated\": 1713888559427,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"fDdJaoU64671xFPa9MwhA\",\n \"focus\": 0.022706274713114812,\n \"gap\": 1\n },\n \"endBinding\": {\n \"elementId\": \"BfCwSE7YpA3RGF2-igdRn\",\n \"focus\": -0.03785862593023361,\n \"gap\": 1\n },\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -5,\n 260\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 6,\n \"versionNonce\": 1817443659,\n \"index\": \"b68V\",\n \"isDeleted\": false,\n \"id\": \"AGohpqt6XpxMC-GpX7G9v\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 570.7042029976678,\n \"y\": 2396.863537772443,\n \"strokeColor\": \"#2f9e44\",\n \"backgroundColor\": \"transparent\",\n \"width\": 44.96666717529297,\n \"height\": 35,\n \"seed\": 58319243,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713888102828,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 28,\n \"fontFamily\": 1,\n \"text\": \"Yes\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"7afFcGJd2KpSWEavfvfXN\",\n \"originalText\": \"Yes\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 99,\n \"versionNonce\": 1673343269,\n \"index\": \"b6A\",\n \"isDeleted\": false,\n \"id\": \"UVod3hpklXlI65WRpoHVD\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 365.6875365853143,\n \"y\": 3424.363537772443,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 490,\n \"height\": 158.33333333333346,\n \"seed\": 2079397387,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"GfFYhOO7nkdzj__kv-Xp2\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"89jFViNnEVyrD5m60_ohU\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713888589330,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 172,\n \"versionNonce\": 1320147595,\n \"index\": \"b6B\",\n \"isDeleted\": false,\n \"id\": \"hee45CuOCyG1hFEPVjPbH\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 429.0208699186476,\n \"y\": 3457.696871105776,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 373.29998779296875,\n \"height\": 105,\n \"seed\": 1116408811,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713888569075,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 28,\n \"fontFamily\": 1,\n \"text\": \"Initiate block building via \\nthe block building routine\\n\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Initiate block building via \\nthe block building routine\\n\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 376,\n \"versionNonce\": 471267301,\n \"index\": \"b6C\",\n \"isDeleted\": false,\n \"id\": \"MS04_q2lUkE2Fcx7K5P8K\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1414.8103436028578,\n \"y\": 3277.788245374781,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 339.6491228070176,\n \"height\": 545.1754385964912,\n \"seed\": 1436714533,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [],\n \"updated\": 1713888432510,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 151,\n \"versionNonce\": 588403773,\n \"index\": \"b6D\",\n \"isDeleted\": false,\n \"id\": \"1j7JJSLUhXz0-zeAUblYF\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1431.857127228589,\n \"y\": 3303.8408769537286,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 218.56666564941406,\n \"height\": 34.73684210526316,\n \"seed\": 1578662277,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713888642046,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 27.789473684210524,\n \"fontFamily\": 1,\n \"text\": \"Payload Status\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Payload Status\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 175,\n \"versionNonce\": 671875749,\n \"index\": \"b6E\",\n \"isDeleted\": false,\n \"id\": \"kcmBQuMn9gYmnZfboXfub\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1447.6173611467175,\n \"y\": 3385.8584208133775,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 278.12177502579976,\n \"height\": 96.49122807017544,\n \"seed\": 2117664997,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [],\n \"updated\": 1713888432510,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 154,\n \"versionNonce\": 219798035,\n \"index\": \"b6F\",\n \"isDeleted\": false,\n \"id\": \"qauwrJylBzjS0k9tzZQwg\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1461.8072476276257,\n \"y\": 3400.0483072942857,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 74.48332977294922,\n \"height\": 26.487788097695216,\n \"seed\": 194092101,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713888642046,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 21.190230478156174,\n \"fontFamily\": 1,\n \"text\": \"Status\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Status\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"text\",\n \"version\": 236,\n \"versionNonce\": 1301726365,\n \"index\": \"b6G\",\n \"isDeleted\": false,\n \"id\": \"FEEWBZmI3Ix3pkmbCrCB5\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1562.3662431556613,\n \"y\": 3443.5450393204296,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 65.5999984741211,\n \"height\": 26.487788097695216,\n \"seed\": 1308609445,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713888642046,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 21.190230478156174,\n \"fontFamily\": 1,\n \"text\": \"VALID\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"VALID\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 265,\n \"versionNonce\": 1147562181,\n \"index\": \"b6H\",\n \"isDeleted\": false,\n \"id\": \"JC-Vn9fgXj43SxqLjvzn1\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1439.7845438092563,\n \"y\": 3520.946140111623,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 278.12177502579976,\n \"height\": 134.12280701754386,\n \"seed\": 900796165,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [],\n \"updated\": 1713888432510,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 225,\n \"versionNonce\": 261824435,\n \"index\": \"b6I\",\n \"isDeleted\": false,\n \"id\": \"FZeBOpvkxLQKqjzP1AtqG\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1465.5533776585853,\n \"y\": 3535.1360265925314,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 189.06666564941406,\n \"height\": 26.487788097695216,\n \"seed\": 1361241701,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713888642046,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 21.190230478156174,\n \"fontFamily\": 1,\n \"text\": \"Latest valid hash\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Latest valid hash\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"text\",\n \"version\": 414,\n \"versionNonce\": 586033405,\n \"index\": \"b6J\",\n \"isDeleted\": false,\n \"id\": \"KyWA3b8pNGkVPuxDY8jgl\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1468.656232835744,\n \"y\": 3577.1380905760193,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 217.4166717529297,\n \"height\": 54.03508771929825,\n \"seed\": 52613573,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713888642047,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 21.614035087719298,\n \"fontFamily\": 1,\n \"text\": \"Fork choice state's \\n Head block hash\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Fork choice state's \\n Head block hash\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 619,\n \"versionNonce\": 702987997,\n \"index\": \"b6K\",\n \"isDeleted\": false,\n \"id\": \"JFqKTwM5SdALx7oNlKxpk\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1354.020869918647,\n \"y\": 3178.8847366028513,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 440,\n \"height\": 824.2909356725146,\n \"seed\": 2026787109,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"89jFViNnEVyrD5m60_ohU\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"s93qZRZJRMi2eWhqVWIl-\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713888777844,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 281,\n \"versionNonce\": 1763881299,\n \"index\": \"b6L\",\n \"isDeleted\": false,\n \"id\": \"0kJubge8I_y94lm3qM3Je\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1393.648062901103,\n \"y\": 3192.2619295853074,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 157.4166717529297,\n \"height\": 44.99999999999999,\n \"seed\": 1603462277,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713888642047,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 35.99999999999999,\n \"fontFamily\": 1,\n \"text\": \"Response\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Response\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 230,\n \"versionNonce\": 1687375269,\n \"index\": \"b6M\",\n \"isDeleted\": false,\n \"id\": \"QwsHDUGaHnLjKIsexW2WM\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1441.3927309437586,\n \"y\": 3690.6098828016816,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 278.12177502579976,\n \"height\": 96.49122807017544,\n \"seed\": 1529744357,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [],\n \"updated\": 1713888432510,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 225,\n \"versionNonce\": 882508125,\n \"index\": \"b6N\",\n \"isDeleted\": false,\n \"id\": \"7eVrIFUotNRuLJelsItIo\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1456.8691671322695,\n \"y\": 3704.7997692825898,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 160.96665954589844,\n \"height\": 26.487788097695212,\n \"seed\": 1001211717,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713888642047,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 21.19023047815617,\n \"fontFamily\": 1,\n \"text\": \"Validation error\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Validation error\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"text\",\n \"version\": 289,\n \"versionNonce\": 2064060147,\n \"index\": \"b6O\",\n \"isDeleted\": false,\n \"id\": \"NK-tse_Cz9XTdLDO853g8\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1557.4281626603051,\n \"y\": 3748.2965013087337,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 33.06666564941406,\n \"height\": 26.487788097695216,\n \"seed\": 1936594597,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713888642047,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 21.190230478156174,\n \"fontFamily\": 1,\n \"text\": \"null\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"null\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 288,\n \"versionNonce\": 1905103813,\n \"index\": \"b6P\",\n \"isDeleted\": false,\n \"id\": \"eT9zmBRRLpyES27rlHXvv\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1446.538929774168,\n \"y\": 3865.5806430355997,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 278.12177502579976,\n \"height\": 96.49122807017544,\n \"seed\": 1293810181,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [],\n \"updated\": 1713888432510,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 293,\n \"versionNonce\": 1743506877,\n \"index\": \"b6Q\",\n \"isDeleted\": false,\n \"id\": \"zFYVAuSiPIiC7yNP1oXc2\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1462.0153659626785,\n \"y\": 3879.770529516508,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 115.75,\n \"height\": 26.487788097695216,\n \"seed\": 1639608677,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713888642047,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 21.190230478156174,\n \"fontFamily\": 1,\n \"text\": \"Payload Id\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Payload Id\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"text\",\n \"version\": 382,\n \"versionNonce\": 2090207563,\n \"index\": \"b6R\",\n \"isDeleted\": false,\n \"id\": \"jpC8xwMgkMpvQeqVGr_vn\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1520.9076948240481,\n \"y\": 3919.9339282093183,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 175.46665954589844,\n \"height\": 26.487788097695216,\n \"seed\": 1318124741,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713888451406,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 21.190230478156174,\n \"fontFamily\": 1,\n \"text\": \"Build process ID\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Build process ID\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"arrow\",\n \"version\": 168,\n \"versionNonce\": 1424268325,\n \"index\": \"b6T\",\n \"isDeleted\": false,\n \"id\": \"-Je4WYHOse5B0zTspiiOU\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 874.0208699186478,\n \"y\": -667.3031288942215,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 210,\n \"height\": 533.3333333333334,\n \"seed\": 2115204197,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"fmJ0sG-s3BF5TzdWA5CyV\"\n }\n ],\n \"updated\": 1713888543639,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"7xM1UGFN1JivXs0OBz6J9\",\n \"focus\": 0.49858797064824334,\n \"gap\": 7.6428571428570535\n },\n \"endBinding\": {\n \"elementId\": \"U0JxI3CJ5fLRkHkd2lJEl\",\n \"focus\": -0.6966680417794964,\n \"gap\": 9.476190476190766\n },\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 166.66666666666652,\n -25\n ],\n [\n 154.99999999999977,\n -486.66666666666663\n ],\n [\n -43.333333333333485,\n -533.3333333333334\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 10,\n \"versionNonce\": 1342722149,\n \"index\": \"b6U\",\n \"isDeleted\": false,\n \"id\": \"fmJ0sG-s3BF5TzdWA5CyV\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1010.8833344347668,\n \"y\": -946.7415657027918,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 122.41666412353516,\n \"height\": 35,\n \"seed\": 179858085,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713888515610,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 28,\n \"fontFamily\": 1,\n \"text\": \"Response\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"-Je4WYHOse5B0zTspiiOU\",\n \"originalText\": \"Response\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"arrow\",\n \"version\": 191,\n \"versionNonce\": 15391013,\n \"index\": \"b6V\",\n \"isDeleted\": false,\n \"id\": \"GfFYhOO7nkdzj__kv-Xp2\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 598.1875365853145,\n \"y\": 3112.696871105778,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 3.3333333333332575,\n \"height\": 300,\n \"seed\": 605710117,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"6jWTMFvOrEIvwz1QyrzLl\"\n }\n ],\n \"updated\": 1713888574764,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"BfCwSE7YpA3RGF2-igdRn\",\n \"focus\": -0.008253202650754538,\n \"gap\": 1.4384467309200488\n },\n \"endBinding\": {\n \"elementId\": \"UVod3hpklXlI65WRpoHVD\",\n \"focus\": -0.03317642628506826,\n \"gap\": 11.666666666665378\n },\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 3.3333333333332575,\n 300\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 10,\n \"versionNonce\": 964035979,\n \"index\": \"b6W\",\n \"isDeleted\": false,\n \"id\": \"6jWTMFvOrEIvwz1QyrzLl\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 674.8708696643346,\n \"y\": 2331.8635377724445,\n \"strokeColor\": \"#2f9e44\",\n \"backgroundColor\": \"transparent\",\n \"width\": 44.96666717529297,\n \"height\": 35,\n \"seed\": 887896709,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713888561135,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 28,\n \"fontFamily\": 1,\n \"text\": \"Yes\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"GfFYhOO7nkdzj__kv-Xp2\",\n \"originalText\": \"Yes\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"arrow\",\n \"version\": 110,\n \"versionNonce\": 1207225939,\n \"index\": \"b6X\",\n \"isDeleted\": false,\n \"id\": \"89jFViNnEVyrD5m60_ohU\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 869.6875365853143,\n \"y\": 3491.363537772445,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 471.6666666666663,\n \"height\": 1.333333333333485,\n \"seed\": 1121873029,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1713888803331,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"UVod3hpklXlI65WRpoHVD\",\n \"focus\": -0.1615194578210893,\n \"gap\": 14\n },\n \"endBinding\": {\n \"elementId\": \"JFqKTwM5SdALx7oNlKxpk\",\n \"focus\": 0.23663599417605152,\n \"gap\": 12.666666666666288\n },\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 471.6666666666663,\n 1.333333333333485\n ]\n ]\n },\n {\n \"id\": \"huqkJN3fbtLAcwIYkDXd7\",\n \"type\": \"arrow\",\n \"x\": 1365.6875365853139,\n \"y\": -425.21979556088684,\n \"width\": 475,\n \"height\": 214.9999999999999,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b6Y\",\n \"roundness\": {\n \"type\": 2\n },\n \"seed\": 1747184349,\n \"version\": 105,\n \"versionNonce\": 1867886611,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713888667480,\n \"link\": null,\n \"locked\": false,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -15,\n -152.4999999999999\n ],\n [\n -475,\n -214.9999999999999\n ]\n ],\n \"lastCommittedPoint\": null,\n \"startBinding\": {\n \"elementId\": \"dGHHPsplaHTpT-MoKae73\",\n \"focus\": 0.19266446613003196,\n \"gap\": 17.095238095234492\n },\n \"endBinding\": {\n \"elementId\": \"7xM1UGFN1JivXs0OBz6J9\",\n \"focus\": -0.16545979439468028,\n \"gap\": 24.309523809523114\n },\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\"\n },\n {\n \"id\": \"qGi_riOg8PM3RPSKlquqk\",\n \"type\": \"arrow\",\n \"x\": 1793.1875365853134,\n \"y\": 2037.8608906372124,\n \"width\": 1394.9999999999995,\n \"height\": 2691.0493872854718,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b6Z\",\n \"roundness\": {\n \"type\": 2\n },\n \"seed\": 1147237117,\n \"version\": 246,\n \"versionNonce\": 1465538653,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713888700326,\n \"link\": null,\n \"locked\": false,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 492.5,\n -24.91712395634697\n ],\n [\n 330,\n -2471.298015416431\n ],\n [\n -902.4999999999995,\n -2691.0493872854718\n ]\n ],\n \"lastCommittedPoint\": null,\n \"startBinding\": {\n \"elementId\": \"K5OOc7V_1CdFK0I-TGGFw\",\n \"focus\": 0.13029514274455564,\n \"gap\": 7.931873479317687\n },\n \"endBinding\": {\n \"elementId\": \"7xM1UGFN1JivXs0OBz6J9\",\n \"focus\": -0.3899412585850232,\n \"gap\": 24.309523809523114\n },\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\"\n },\n {\n \"type\": \"arrow\",\n \"version\": 438,\n \"versionNonce\": 146202835,\n \"index\": \"b6a\",\n \"isDeleted\": false,\n \"id\": \"q5UbeysotrMmQ8Efoacdh\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1793.6025281284742,\n \"y\": 2837.5788075510877,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 2019.9999999999995,\n \"height\": 4081.1322633291247,\n \"seed\": 1562915219,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1713888727250,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"wk0Rw2YteS3p5_V33a08d\",\n \"focus\": -0.5535468892889344,\n \"gap\": 1\n },\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 1142.4999999999995,\n 605.082876043653\n ],\n [\n 827.5,\n -3371.2980154164306\n ],\n [\n -877.5,\n -3476.0493872854718\n ]\n ]\n },\n {\n \"type\": \"arrow\",\n \"version\": 616,\n \"versionNonce\": 6319005,\n \"index\": \"b6b\",\n \"isDeleted\": false,\n \"id\": \"s93qZRZJRMi2eWhqVWIl-\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1796.7814670458931,\n \"y\": 3707.847669463127,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 2239.528127240689,\n \"height\": 4986.380891460083,\n \"seed\": 1871017629,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1713888778466,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"JFqKTwM5SdALx7oNlKxpk\",\n \"focus\": 0.023031090580857373,\n \"gap\": 2.7605971272462284\n },\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 1337.5239531546965,\n 630.082876043653\n ],\n [\n 1122.1891214315203,\n -4356.298015416431\n ],\n [\n -902.0041740859926,\n -4351.049387285471\n ]\n ]\n },\n {\n \"id\": \"uWWBuHlYAWJGil5tufuaT\",\n \"type\": \"arrow\",\n \"x\": 600.7112800819702,\n \"y\": -603.4697955608898,\n \"width\": 2.7603067399340944,\n \"height\": 118.55797152562593,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b6c\",\n \"roundness\": {\n \"type\": 2\n },\n \"seed\": 517447869,\n \"version\": 126,\n \"versionNonce\": 1257978419,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713888851558,\n \"link\": null,\n \"locked\": false,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -2.7603067399340944,\n 118.55797152562593\n ]\n ],\n \"lastCommittedPoint\": null,\n \"startBinding\": {\n \"elementId\": \"7xM1UGFN1JivXs0OBz6J9\",\n \"focus\": -0.1668246446169939,\n \"gap\": 10.864145658264249\n },\n \"endBinding\": {\n \"elementId\": \"29B4xiJVviN_LhIJNJ7YK\",\n \"focus\": -0.02108947048083296,\n \"gap\": 1\n },\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\"\n },\n {\n \"id\": \"LvTIe8okvOyBDOMpzZlDI\",\n \"type\": \"rectangle\",\n \"x\": -1369.3124634146843,\n \"y\": -1645.969795560889,\n \"width\": 4774.999999999996,\n \"height\": 6584.9999999999945,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b6d\",\n \"roundness\": {\n \"type\": 3\n },\n \"seed\": 1409452403,\n \"version\": 92,\n \"versionNonce\": 1475287379,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713888872035,\n \"link\": null,\n \"locked\": false\n },\n {\n \"id\": \"3coEbfOkmFqKB89oNSUD2\",\n \"type\": \"text\",\n \"x\": -1234.3124634146843,\n \"y\": -1550.9697955608885,\n \"width\": 1445.61669921875,\n \"height\": 183.6219412191702,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b6h\",\n \"roundness\": null,\n \"seed\": 892306077,\n \"version\": 163,\n \"versionNonce\": 630518067,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713888916991,\n \"link\": null,\n \"locked\": false,\n \"text\": \"Fork choice updated\",\n \"fontSize\": 146.89755297533617,\n \"fontFamily\": 1,\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Fork choice updated\",\n \"lineHeight\": 1.25\n }\n ],\n \"appState\": {\n \"gridSize\": null,\n \"viewBackgroundColor\": \"#ffffff\"\n },\n \"files\": {}\n}" }, { "path": "docs/images/el-architecture/excalidraw/payload-building-routine.excalidraw", "content": "{\n \"type\": \"excalidraw\",\n \"version\": 2,\n \"source\": \"https://excalidraw.com\",\n \"elements\": [\n {\n \"id\": \"jWb2T3fCwkij29ZlP0BWz\",\n \"type\": \"rectangle\",\n \"x\": 1494.4654849656945,\n \"y\": -221.031996178564,\n \"width\": 309.71646797023016,\n \"height\": 596.3796066093429,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b2p\",\n \"roundness\": {\n \"type\": 3\n },\n \"seed\": 478962891,\n \"version\": 1168,\n \"versionNonce\": 18965931,\n \"isDeleted\": false,\n \"boundElements\": [\n {\n \"id\": \"jO5vChDiz-GVV1Uh1qQCi\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713875025994,\n \"link\": null,\n \"locked\": false\n },\n {\n \"id\": \"k4g6_US5onQ29XgawnM04\",\n \"type\": \"text\",\n \"x\": 1546.2422882944509,\n \"y\": -121.65085285414216,\n \"width\": 199.06666564941415,\n \"height\": 442.26436087949713,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b2q\",\n \"roundness\": null,\n \"seed\": 1239737323,\n \"version\": 1190,\n \"versionNonce\": 307105157,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713875379563,\n \"link\": null,\n \"locked\": false,\n \"text\": \".\\n.\\n.\\n\\n\\ntransactions\\n\\n.\\n.\\n.\\n\",\n \"fontSize\": 32.16468079123616,\n \"fontFamily\": 1,\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \".\\n.\\n.\\n\\n\\ntransactions\\n\\n.\\n.\\n.\\n\",\n \"lineHeight\": 1.25\n },\n {\n \"id\": \"RUGNxN3EwKK_b-QrOBlBN\",\n \"type\": \"text\",\n \"x\": 1528.5443196290855,\n \"y\": -197.97866684744645,\n \"width\": 240.6176996304714,\n \"height\": 33.39129999759148,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b2r\",\n \"roundness\": null,\n \"seed\": 1251422443,\n \"version\": 1121,\n \"versionNonce\": 1573369899,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713875025994,\n \"link\": null,\n \"locked\": false,\n \"text\": \"Execution Payload\",\n \"fontSize\": 26.713039998073185,\n \"fontFamily\": 1,\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Execution Payload\",\n \"lineHeight\": 1.25\n },\n {\n \"id\": \"1oLAKeS_wwmO2k3mok9uB\",\n \"type\": \"rectangle\",\n \"x\": -268.10376134978856,\n \"y\": -585.684081275177,\n \"width\": 3151.0476190476193,\n \"height\": 1729.1904761904761,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b36\",\n \"roundness\": {\n \"type\": 3\n },\n \"seed\": 1468825605,\n \"version\": 431,\n \"versionNonce\": 184968619,\n \"isDeleted\": false,\n \"boundElements\": [\n {\n \"id\": \"bOdiE38wCtUN6e81IgiX9\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"TJdFCkbobxr71YBZ3zIY3\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713875444138,\n \"link\": null,\n \"locked\": false\n },\n {\n \"id\": \"i744TP7q5bj-L4gf8AiYw\",\n \"type\": \"text\",\n \"x\": -233.2228089688357,\n \"y\": -576.8031288942248,\n \"width\": 613.4666748046875,\n \"height\": 64.00270956400504,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b39\",\n \"roundness\": null,\n \"seed\": 1269922059,\n \"version\": 100,\n \"versionNonce\": 1852392645,\n \"isDeleted\": false,\n \"boundElements\": [],\n \"updated\": 1713875760558,\n \"link\": null,\n \"locked\": false,\n \"text\": \"Payload Building Routine\",\n \"fontSize\": 51.202167651204036,\n \"fontFamily\": 1,\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Payload Building Routine\",\n \"lineHeight\": 1.25\n },\n {\n \"id\": \"eJzppWP0wlePph6wAu74g\",\n \"type\": \"rectangle\",\n \"x\": -958.9553205575423,\n \"y\": -427.4697955608909,\n \"width\": 458.57142857142856,\n \"height\": 578.5714285714284,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b3i\",\n \"roundness\": {\n \"type\": 3\n },\n \"seed\": 1756550187,\n \"version\": 93,\n \"versionNonce\": 1342203685,\n \"isDeleted\": false,\n \"boundElements\": [\n {\n \"id\": \"bOdiE38wCtUN6e81IgiX9\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713869493924,\n \"link\": null,\n \"locked\": false\n },\n {\n \"id\": \"0XdEMNgLQNhkN_b0KC-jd\",\n \"type\": \"text\",\n \"x\": -930.3838919861138,\n \"y\": -293.89836698946226,\n \"width\": 397.1833190917969,\n \"height\": 350,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b3j\",\n \"roundness\": null,\n \"seed\": 1231428549,\n \"version\": 183,\n \"versionNonce\": 1400779851,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713869483620,\n \"link\": null,\n \"locked\": false,\n \"text\": \" Timestamp \\n \\n Prev Randao \\n \\n Suggested Fee Recipient\\n \\n Withdrawls \\n \\n Parent Beacon Block Root \\n\",\n \"fontSize\": 28,\n \"fontFamily\": 1,\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \" Timestamp \\n \\n Prev Randao \\n \\n Suggested Fee Recipient\\n \\n Withdrawls \\n \\n Parent Beacon Block Root \\n\",\n \"lineHeight\": 1.25\n },\n {\n \"id\": \"8G7UBytqp3Gae84000SPE\",\n \"type\": \"text\",\n \"x\": -934.669606271828,\n \"y\": -391.7555098466052,\n \"width\": 266.4333190917969,\n \"height\": 35,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b3k\",\n \"roundness\": null,\n \"seed\": 154544459,\n \"version\": 92,\n \"versionNonce\": 1575449323,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713869483620,\n \"link\": null,\n \"locked\": false,\n \"text\": \"Payload Attributes\",\n \"fontSize\": 28,\n \"fontFamily\": 1,\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Payload Attributes\",\n \"lineHeight\": 1.25\n },\n {\n \"id\": \"Z0XygtdTQfbzWa-wRKA-r\",\n \"type\": \"text\",\n \"x\": -158.47913008135185,\n \"y\": 512.7682996772046,\n \"width\": 208.01666259765625,\n \"height\": 35,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b3m\",\n \"roundness\": null,\n \"seed\": 1923348715,\n \"version\": 434,\n \"versionNonce\": 1458026661,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713874643472,\n \"link\": null,\n \"locked\": false,\n \"text\": \"1. Generate ID\",\n \"fontSize\": 28,\n \"fontFamily\": 1,\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"1. Generate ID\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 605,\n \"versionNonce\": 417674661,\n \"index\": \"b3n\",\n \"isDeleted\": false,\n \"id\": \"Kzkmeiz0aCo2d_h6zoGgK\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -137.05055865278052,\n \"y\": 224.6730615819664,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 197.1428571428571,\n \"height\": 136.00361663652788,\n \"seed\": 117014507,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"CNDvd5iNr4Xo5en7u4Jre\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713875778592,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 581,\n \"versionNonce\": 145986405,\n \"index\": \"b3o\",\n \"isDeleted\": false,\n \"id\": \"qpu_0IdjurDp-DxDunQNs\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -110.38087812234099,\n \"y\": 254.51332680197856,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 146.1936239736757,\n \"height\": 65.4249547920433,\n \"seed\": 121129611,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713874643472,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 26.169981916817317,\n \"fontFamily\": 1,\n \"text\": \"\\nPayload-ID\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"\\nPayload-ID\",\n \"lineHeight\": 1.25\n },\n {\n \"id\": \"bOdiE38wCtUN6e81IgiX9\",\n \"type\": \"arrow\",\n \"x\": -491.81246341468545,\n \"y\": -99.63683099231491,\n \"width\": 222.0476190476195,\n \"height\": 11.765957290896608,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b3p\",\n \"roundness\": {\n \"type\": 2\n },\n \"seed\": 1806619813,\n \"version\": 600,\n \"versionNonce\": 15525125,\n \"isDeleted\": false,\n \"boundElements\": [],\n \"updated\": 1713875044558,\n \"link\": null,\n \"locked\": false,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 222.0476190476195,\n 11.765957290896608\n ]\n ],\n \"lastCommittedPoint\": null,\n \"startBinding\": {\n \"elementId\": \"eJzppWP0wlePph6wAu74g\",\n \"gap\": 8.571428571428385,\n \"focus\": 0.08641975308642126\n },\n \"endBinding\": {\n \"elementId\": \"1oLAKeS_wwmO2k3mok9uB\",\n \"gap\": 1.6610830172776332,\n \"focus\": 0.2987190151389121\n },\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\"\n },\n {\n \"id\": \"fhM_iIiJD3RAsMYBBDthq\",\n \"type\": \"arrow\",\n \"x\": -108.80747081928959,\n \"y\": 899.2857872454151,\n \"width\": 2916.0075977303836,\n \"height\": 0,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b3s\",\n \"roundness\": {\n \"type\": 2\n },\n \"seed\": 1253747147,\n \"version\": 337,\n \"versionNonce\": 1529760011,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713875334625,\n \"link\": null,\n \"locked\": false,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 2916.0075977303836,\n 0\n ]\n ],\n \"lastCommittedPoint\": null,\n \"startBinding\": null,\n \"endBinding\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\"\n },\n {\n \"id\": \"1YgZ6OeGavZ4TJsZZBANt\",\n \"type\": \"text\",\n \"x\": 1087.2167345922405,\n \"y\": 943.3254382198705,\n \"width\": 110.3077348944564,\n \"height\": 62.58266191106846,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b3t\",\n \"roundness\": null,\n \"seed\": 883833099,\n \"version\": 148,\n \"versionNonce\": 1820254501,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713875334625,\n \"link\": null,\n \"locked\": false,\n \"text\": \"Time\",\n \"fontSize\": 50.06612952885477,\n \"fontFamily\": 1,\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Time\",\n \"lineHeight\": 1.25\n },\n {\n \"id\": \"j1Soej0arH7iLa0xZ6cY7\",\n \"type\": \"text\",\n \"x\": -136.62198722420908,\n \"y\": 776.4383397903553,\n \"width\": 414.45946753809073,\n \"height\": 62.58266191106846,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b3u\",\n \"roundness\": null,\n \"seed\": 183868293,\n \"version\": 149,\n \"versionNonce\": 1211559851,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713875334625,\n \"link\": null,\n \"locked\": false,\n \"text\": \"T0 = TimeStamp\",\n \"fontSize\": 50.06612952885477,\n \"fontFamily\": 1,\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"T0 = TimeStamp\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"text\",\n \"version\": 259,\n \"versionNonce\": 783381637,\n \"index\": \"b3v\",\n \"isDeleted\": false,\n \"id\": \"wiBuw72GsX8BLbRrot537\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 2111.3876953970653,\n \"y\": 762.8361608385717,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 690.1940345066464,\n \"height\": 62.58266191106846,\n \"seed\": 867162699,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713875334625,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 50.06612952885477,\n \"fontFamily\": 1,\n \"text\": \"TMax = TimeStamp + 12sec\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"TMax = TimeStamp + 12sec\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 562,\n \"versionNonce\": 1041620677,\n \"index\": \"b3w\",\n \"isDeleted\": false,\n \"id\": \"aZV4HyDKcREKI3xck6Q8M\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 239.87801277579103,\n \"y\": -359.37455746565263,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 417.3333333333332,\n \"height\": 803.6030204962242,\n \"seed\": 1047840011,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [],\n \"updated\": 1713874643472,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 605,\n \"versionNonce\": 1540865573,\n \"index\": \"b3x\",\n \"isDeleted\": false,\n \"id\": \"kyHLf-mTt9La3dG_10zVF\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 324.03119508431223,\n \"y\": -236.1113427946711,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 264.0333251953125,\n \"height\": 675.2966558791799,\n \"seed\": 1968040875,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713874643472,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 27.011866235167197,\n \"fontFamily\": 1,\n \"text\": \"parentHash\\nfeeRecipient\\nlogsBloom\\nprevRandao\\nblockNumber\\ngasLimit\\ngasUsed: Empty\\ntimestamp\\nextraData\\nbaseFeePerGas\\nblobGasUsed\\nexcessBlobGas\\nblockHash\\n\\ntransactions: Empty\\n\\nwithdrawals\\nstateRoot: Empty\\nreceiptsRoot: Empty\\n\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"parentHash\\nfeeRecipient\\nlogsBloom\\nprevRandao\\nblockNumber\\ngasLimit\\ngasUsed: Empty\\ntimestamp\\nextraData\\nbaseFeePerGas\\nblobGasUsed\\nexcessBlobGas\\nblockHash\\n\\ntransactions: Empty\\n\\nwithdrawals\\nstateRoot: Empty\\nreceiptsRoot: Empty\\n\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"text\",\n \"version\": 490,\n \"versionNonce\": 1491513733,\n \"index\": \"b3y\",\n \"isDeleted\": false,\n \"id\": \"ruSS4VXoQgaN5cWHvvifh\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 285.79818537557526,\n \"y\": -328.31091129521036,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 243.30937686990117,\n \"height\": 33.764832793959,\n \"seed\": 1334394443,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713874643472,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 27.011866235167197,\n \"fontFamily\": 1,\n \"text\": \"Execution Payload\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Execution Payload\",\n \"lineHeight\": 1.25\n },\n {\n \"id\": \"GEoPP15dJB1JRdsbZ_dkq\",\n \"type\": \"text\",\n \"x\": 244.37801277579092,\n \"y\": 526.4587758676805,\n \"width\": 418.5833435058594,\n \"height\": 45,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b40\",\n \"roundness\": null,\n \"seed\": 680965189,\n \"version\": 194,\n \"versionNonce\": 1921005797,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713874643472,\n \"link\": null,\n \"locked\": false,\n \"text\": \"2. Build Initial Payload\",\n \"fontSize\": 36,\n \"fontFamily\": 1,\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"2. Build Initial Payload\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"text\",\n \"version\": 278,\n \"versionNonce\": 82636523,\n \"index\": \"b41\",\n \"isDeleted\": false,\n \"id\": \"rOHxJbplE4mT9ktNxWTYJ\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1099.0782722614802,\n \"y\": 527.1877692053496,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 337.7646894015348,\n \"height\": 45.10433999566458,\n \"seed\": 230587621,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713874705657,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 36.08347199653167,\n \"fontFamily\": 1,\n \"text\": \"3. Update Payload\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"3. Update Payload\",\n \"lineHeight\": 1.25\n },\n {\n \"id\": \"EB5k_JLxqfIlHeseC0cRp\",\n \"type\": \"rectangle\",\n \"x\": 1025.0446794424574,\n \"y\": -858.7604563038813,\n \"width\": 248.92072886448233,\n \"height\": 165.34779998554862,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b42\",\n \"roundness\": {\n \"type\": 3\n },\n \"seed\": 1041501611,\n \"version\": 542,\n \"versionNonce\": 1160524581,\n \"isDeleted\": false,\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"Wnb_NxriffoVboYYccW-E\"\n },\n {\n \"id\": \"uHlBvTZ00-8r4Tm2BztCm\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713874991724,\n \"link\": null,\n \"locked\": false\n },\n {\n \"id\": \"Wnb_NxriffoVboYYccW-E\",\n \"type\": \"text\",\n \"x\": 1033.5300454005774,\n \"y\": -821.1908963067716,\n \"width\": 231.9499969482422,\n \"height\": 90.20867999132918,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b43\",\n \"roundness\": null,\n \"seed\": 1472600645,\n \"version\": 610,\n \"versionNonce\": 1776584325,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713874991724,\n \"link\": null,\n \"locked\": false,\n \"text\": \"Transactions\\n(mempool)\",\n \"fontSize\": 36.08347199653167,\n \"fontFamily\": 1,\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"EB5k_JLxqfIlHeseC0cRp\",\n \"originalText\": \"Transactions(mempool)\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 379,\n \"versionNonce\": 1944072773,\n \"index\": \"b44\",\n \"isDeleted\": false,\n \"id\": \"GermJiqvZtwW27lxcXqVD\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1050.5159778753314,\n \"y\": -28.340079221208214,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 162.37001107898413,\n \"height\": 84.74969636085194,\n \"seed\": 995774117,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"jbgmT-7UpxU67gJZXe2-u\"\n },\n {\n \"id\": \"ywlt4Hfk73TDP8EOaEhw2\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"u8f_lnvJmoGjaG0bBkBN5\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713875013110,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 492,\n \"versionNonce\": 1014392773,\n \"index\": \"b45\",\n \"isDeleted\": false,\n \"id\": \"jbgmT-7UpxU67gJZXe2-u\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1101.8926509715861,\n \"y\": -5.0118823861017425,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 59.61666488647461,\n \"height\": 38.093302690639,\n \"seed\": 985870853,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713875013110,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 30.4746421525112,\n \"fontFamily\": 1,\n \"text\": \"EVM\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"GermJiqvZtwW27lxcXqVD\",\n \"originalText\": \"EVM\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 328,\n \"versionNonce\": 792667941,\n \"index\": \"b46\",\n \"isDeleted\": false,\n \"id\": \"duUccHNGk8gT8rXhoYNxG\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1029.4019882380258,\n \"y\": 151.83263235046712,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 210.22838759021047,\n \"height\": 139.64606941784677,\n \"seed\": 268853067,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"Lk3CokcSvqp1X43XjdLio\"\n },\n {\n \"id\": \"ywlt4Hfk73TDP8EOaEhw2\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"u8f_lnvJmoGjaG0bBkBN5\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713875013110,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 467,\n \"versionNonce\": 935586981,\n \"index\": \"b47\",\n \"isDeleted\": false,\n \"id\": \"Lk3CokcSvqp1X43XjdLio\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1055.1578522601817,\n \"y\": 183.5623643687515,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 158.71665954589844,\n \"height\": 76.186605381278,\n \"seed\": 1311915499,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713875013111,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 30.4746421525112,\n \"fontFamily\": 1,\n \"text\": \"Transient \\nState\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"duUccHNGk8gT8rXhoYNxG\",\n \"originalText\": \"Transient State\",\n \"lineHeight\": 1.25\n },\n {\n \"id\": \"ywlt4Hfk73TDP8EOaEhw2\",\n \"type\": \"arrow\",\n \"x\": 1089.4730041402122,\n \"y\": 140.01490712847516,\n \"width\": 23.929188255613063,\n \"height\": 81.64075993091534,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b48\",\n \"roundness\": {\n \"type\": 2\n },\n \"seed\": 1543182437,\n \"version\": 185,\n \"versionNonce\": 932524459,\n \"isDeleted\": false,\n \"boundElements\": [],\n \"updated\": 1713875016185,\n \"link\": null,\n \"locked\": false,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 23.929188255613063,\n -81.64075993091534\n ]\n ],\n \"lastCommittedPoint\": null,\n \"startBinding\": {\n \"elementId\": \"duUccHNGk8gT8rXhoYNxG\",\n \"focus\": -0.5492323976338936,\n \"gap\": 11.817725221991964\n },\n \"endBinding\": {\n \"elementId\": \"GermJiqvZtwW27lxcXqVD\",\n \"focus\": 0.05665032764323953,\n \"gap\": 1.9645300579160931\n },\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\"\n },\n {\n \"id\": \"u8f_lnvJmoGjaG0bBkBN5\",\n \"type\": \"arrow\",\n \"x\": 1176.7441613077424,\n \"y\": 66.81974305248212,\n \"width\": 26.744386873920615,\n \"height\": 84.4559585492227,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b4A\",\n \"roundness\": {\n \"type\": 2\n },\n \"seed\": 516289643,\n \"version\": 186,\n \"versionNonce\": 1504641771,\n \"isDeleted\": false,\n \"boundElements\": [],\n \"updated\": 1713875016186,\n \"link\": null,\n \"locked\": false,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -26.744386873920615,\n 84.4559585492227\n ]\n ],\n \"lastCommittedPoint\": null,\n \"startBinding\": {\n \"elementId\": \"GermJiqvZtwW27lxcXqVD\",\n \"focus\": -0.6528118331206174,\n \"gap\": 10.410125912838396\n },\n \"endBinding\": {\n \"elementId\": \"duUccHNGk8gT8rXhoYNxG\",\n \"focus\": -0.05347538776799649,\n \"gap\": 1\n },\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\"\n },\n {\n \"id\": \"whl7O7iYacCcjhiqqiY9G\",\n \"type\": \"rectangle\",\n \"x\": 936.0446794424574,\n \"y\": -144.32015332057495,\n \"width\": 380.33333333333326,\n \"height\": 478.8652849740933,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b4C\",\n \"roundness\": {\n \"type\": 3\n },\n \"seed\": 675354699,\n \"version\": 106,\n \"versionNonce\": 1595066213,\n \"isDeleted\": false,\n \"boundElements\": [\n {\n \"id\": \"uHlBvTZ00-8r4Tm2BztCm\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"jO5vChDiz-GVV1Uh1qQCi\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713875013111,\n \"link\": null,\n \"locked\": false\n },\n {\n \"id\": \"KTC1QuQRSxtdZN7hZpS-_\",\n \"type\": \"text\",\n \"x\": 1016.277840064219,\n \"y\": -118.98336575580808,\n \"width\": 247.32927976618157,\n \"height\": 76.01036269430053,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b4D\",\n \"roundness\": null,\n \"seed\": 1307686443,\n \"version\": 61,\n \"versionNonce\": 1212440907,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713875013111,\n \"link\": null,\n \"locked\": false,\n \"text\": \"Fill and process \\nTransactions\",\n \"fontSize\": 30.40414507772021,\n \"fontFamily\": 1,\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Fill and process \\nTransactions\",\n \"lineHeight\": 1.25\n },\n {\n \"id\": \"jO5vChDiz-GVV1Uh1qQCi\",\n \"type\": \"arrow\",\n \"x\": 1321.0446794424574,\n \"y\": 67.34090193315706,\n \"width\": 158,\n \"height\": 34.23988998261099,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b4E\",\n \"roundness\": {\n \"type\": 2\n },\n \"seed\": 1072183301,\n \"version\": 200,\n \"versionNonce\": 2033749515,\n \"isDeleted\": false,\n \"boundElements\": [],\n \"updated\": 1713875030582,\n \"link\": null,\n \"locked\": false,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 158,\n 34.23988998261099\n ]\n ],\n \"lastCommittedPoint\": null,\n \"startBinding\": {\n \"elementId\": \"whl7O7iYacCcjhiqqiY9G\",\n \"focus\": -0.24940398840884656,\n \"gap\": 4.666666666666856\n },\n \"endBinding\": {\n \"elementId\": \"jWb2T3fCwkij29ZlP0BWz\",\n \"focus\": -0.18485020656662557,\n \"gap\": 15.42080552323705\n },\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\"\n },\n {\n \"id\": \"uHlBvTZ00-8r4Tm2BztCm\",\n \"type\": \"arrow\",\n \"x\": 1147.7689254849781,\n \"y\": -686.041224132319,\n \"width\": 19.908011376410514,\n \"height\": 529.5544041450777,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b4G\",\n \"roundness\": {\n \"type\": 2\n },\n \"seed\": 1954525925,\n \"version\": 255,\n \"versionNonce\": 1721212715,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713875013602,\n \"link\": null,\n \"locked\": false,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -19.908011376410514,\n 529.5544041450777\n ]\n ],\n \"lastCommittedPoint\": null,\n \"startBinding\": {\n \"elementId\": \"EB5k_JLxqfIlHeseC0cRp\",\n \"gap\": 7.371432186013635,\n \"focus\": -0.01292668229715335\n },\n \"endBinding\": {\n \"elementId\": \"whl7O7iYacCcjhiqqiY9G\",\n \"gap\": 12.166666666666401,\n \"focus\": -0.039208278580814056\n },\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\"\n },\n {\n \"type\": \"text\",\n \"version\": 362,\n \"versionNonce\": 904726059,\n \"index\": \"b4H\",\n \"isDeleted\": false,\n \"id\": \"04EolSOKKYqyoVm8vz9KA\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 2164.16233474169,\n \"y\": 519.4066058698485,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 408.76666259765625,\n \"height\": 90.20867999132918,\n \"seed\": 321213963,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713875145606,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 36.08347199653167,\n \"fontFamily\": 1,\n \"text\": \"4. Process withdrawals\\n & add state root \",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"4. Process withdrawals\\n & add state root \",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 451,\n \"versionNonce\": 1380050661,\n \"index\": \"b4I\",\n \"isDeleted\": false,\n \"id\": \"kjtQk7GZ20g1k1vmqTkCf\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 2072.2131001140474,\n \"y\": 53.2315965936956,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 193.77640810167594,\n \"height\": 74.61086765994742,\n \"seed\": 318020741,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"ujIN4E25VH4TzxFQnlyhh\"\n },\n {\n \"id\": \"1ayAHRPajP3QPk8cWo3hH\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713875229538,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 610,\n \"versionNonce\": 1130083589,\n \"index\": \"b4J\",\n \"isDeleted\": false,\n \"id\": \"ujIN4E25VH4TzxFQnlyhh\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 2078.751305690764,\n \"y\": 72.992744215141,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 180.6999969482422,\n \"height\": 35.08857241705661,\n \"seed\": 697877477,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713875229539,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 28.070857933645286,\n \"fontFamily\": 1,\n \"text\": \"Withdrawalas\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"kjtQk7GZ20g1k1vmqTkCf\",\n \"originalText\": \"Withdrawalas\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 362,\n \"versionNonce\": 799364843,\n \"index\": \"b4K\",\n \"isDeleted\": false,\n \"id\": \"Jgr3UJ6RE8E0nc3VKIzw4\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 2074.8714672404203,\n \"y\": 267.09094791870064,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 193.64595561552252,\n \"height\": 128.63104203168882,\n \"seed\": 1543569221,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"edTog9SDZ8ZTP-bHRvrqn\"\n },\n {\n \"id\": \"1ayAHRPajP3QPk8cWo3hH\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"221majy0mQLKHsudFZJAM\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713875301579,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 525,\n \"versionNonce\": 1740278405,\n \"index\": \"b4L\",\n \"isDeleted\": false,\n \"id\": \"edTog9SDZ8ZTP-bHRvrqn\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 2098.6111091717166,\n \"y\": 296.3178965174884,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 146.1666717529297,\n \"height\": 70.17714483411322,\n \"seed\": 1082838693,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713875229540,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 28.070857933645286,\n \"fontFamily\": 1,\n \"text\": \"Transient \\nState\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"Jgr3UJ6RE8E0nc3VKIzw4\",\n \"originalText\": \"Transient State\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"arrow\",\n \"version\": 441,\n \"versionNonce\": 749010149,\n \"index\": \"b4N\",\n \"isDeleted\": false,\n \"id\": \"1ayAHRPajP3QPk8cWo3hH\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 2225.382387015618,\n \"y\": 137.43145841174385,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 39.77343470658342,\n \"height\": 128.73836768399443,\n \"seed\": 688466277,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1713875229651,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"kjtQk7GZ20g1k1vmqTkCf\",\n \"focus\": -0.6527685616244215,\n \"gap\": 9.588994158100832\n },\n \"endBinding\": {\n \"elementId\": \"Jgr3UJ6RE8E0nc3VKIzw4\",\n \"focus\": -0.053475387767992384,\n \"gap\": 1\n },\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -39.77343470658342,\n 128.73836768399443\n ]\n ]\n },\n {\n \"type\": \"rectangle\",\n \"version\": 139,\n \"versionNonce\": 1438337771,\n \"index\": \"b4O\",\n \"isDeleted\": false,\n \"id\": \"VU7RSkePf5y3TL2B2qAgF\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1988.878012775791,\n \"y\": -5.701845893977065,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 350.33333333333326,\n \"height\": 441.09326424870466,\n \"seed\": 726185157,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [],\n \"updated\": 1713875229540,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"rectangle\",\n \"version\": 1193,\n \"versionNonce\": 1768347691,\n \"index\": \"b4Q\",\n \"isDeleted\": false,\n \"id\": \"UnpGGSfyTGVbgLDZAhti9\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 2448.1864454573424,\n \"y\": -180.23102743699047,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 309.71646797023016,\n \"height\": 596.3796066093429,\n \"seed\": 59058411,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"221majy0mQLKHsudFZJAM\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713875301580,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 1219,\n \"versionNonce\": 579898123,\n \"index\": \"b4R\",\n \"isDeleted\": false,\n \"id\": \"UgRK2EG6mHzgNqfsyv137\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 2502.463248786099,\n \"y\": -80.84988411256865,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 16.08333396911621,\n \"height\": 281.4409569233164,\n \"seed\": 644273035,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713875282074,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 32.16468079123616,\n \"fontFamily\": 1,\n \"text\": \".\\n.\\n.\\n.\\n.\\n.\\n\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \".\\n.\\n.\\n.\\n.\\n.\\n\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"text\",\n \"version\": 1145,\n \"versionNonce\": 771813803,\n \"index\": \"b4S\",\n \"isDeleted\": false,\n \"id\": \"CI-gSHqkFkGjrR_FtjPrE\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 2482.265280120733,\n \"y\": -157.17769810587293,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 240.6176996304714,\n \"height\": 33.39129999759148,\n \"seed\": 1627007531,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713875282074,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 26.713039998073185,\n \"fontFamily\": 1,\n \"text\": \"Execution Payload\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Execution Payload\",\n \"lineHeight\": 1.25\n },\n {\n \"id\": \"Q7vcsIZG4j02TeyKJGQNw\",\n \"type\": \"text\",\n \"x\": 2483.0446794424574,\n \"y\": 299.95877586768097,\n \"width\": 206.56666564941406,\n \"height\": 45,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b4U\",\n \"roundness\": null,\n \"seed\": 565803717,\n \"version\": 37,\n \"versionNonce\": 1206617163,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713875282074,\n \"link\": null,\n \"locked\": false,\n \"text\": \" stateRoot\",\n \"fontSize\": 36,\n \"fontFamily\": 1,\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \" stateRoot\",\n \"lineHeight\": 1.25\n },\n {\n \"id\": \"221majy0mQLKHsudFZJAM\",\n \"type\": \"arrow\",\n \"x\": 2275.0446794424574,\n \"y\": 331.95877586768097,\n \"width\": 178,\n \"height\": 4,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b4V\",\n \"roundness\": {\n \"type\": 2\n },\n \"seed\": 1732849035,\n \"version\": 34,\n \"versionNonce\": 741575525,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713875301599,\n \"link\": null,\n \"locked\": false,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 178,\n -4\n ]\n ],\n \"lastCommittedPoint\": null,\n \"startBinding\": {\n \"elementId\": \"Jgr3UJ6RE8E0nc3VKIzw4\",\n \"focus\": 0.043235480741469205,\n \"gap\": 6.527256586514795\n },\n \"endBinding\": {\n \"elementId\": \"UnpGGSfyTGVbgLDZAhti9\",\n \"focus\": -0.6849516869186505,\n \"gap\": 1\n },\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\"\n },\n {\n \"id\": \"sXIAKri50_wjoyQFouAmw\",\n \"type\": \"rectangle\",\n \"x\": 3073.544679442457,\n \"y\": -156.29122413231903,\n \"width\": 457.49999999999955,\n \"height\": 549.9999999999998,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b4W\",\n \"roundness\": {\n \"type\": 3\n },\n \"seed\": 39233189,\n \"version\": 72,\n \"versionNonce\": 1097021163,\n \"isDeleted\": false,\n \"boundElements\": [\n {\n \"id\": \"TJdFCkbobxr71YBZ3zIY3\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713875444138,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"rectangle\",\n \"version\": 615,\n \"versionNonce\": 1453158245,\n \"index\": \"b4X\",\n \"isDeleted\": false,\n \"id\": \"AjZJn9s1uN0y_0bWRc3XQ\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 3189.9732508710285,\n \"y\": -119.29303245058298,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 197.1428571428571,\n \"height\": 136.00361663652788,\n \"seed\": 649423013,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [],\n \"updated\": 1713875377487,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 600,\n \"versionNonce\": 1784953541,\n \"index\": \"b4Y\",\n \"isDeleted\": false,\n \"id\": \"RJInYSALTs2FaJkU3Fkkz\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 3216.642931401468,\n \"y\": -89.45276723057083,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 146.1936239736757,\n \"height\": 65.4249547920433,\n \"seed\": 2141916165,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713875377487,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 26.169981916817317,\n \"fontFamily\": 1,\n \"text\": \"\\nPayload-ID\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"\\nPayload-ID\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 1287,\n \"versionNonce\": 1558527557,\n \"index\": \"b4Z\",\n \"isDeleted\": false,\n \"id\": \"s45ziPI6Z_R8HDoqtTunW\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 3161.1864454573415,\n \"y\": 123.01897256300956,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 304.7164679702301,\n \"height\": 191.37960660934306,\n \"seed\": 701089835,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [],\n \"updated\": 1713875415082,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 1181,\n \"versionNonce\": 2116873317,\n \"index\": \"b4b\",\n \"isDeleted\": false,\n \"id\": \"o-2WLKjqtxtLhlaDj7OCH\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 3187.7652801207328,\n \"y\": 201.07230189412707,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 240.6176996304714,\n \"height\": 33.39129999759148,\n \"seed\": 1670379883,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713875396939,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 26.713039998073185,\n \"fontFamily\": 1,\n \"text\": \"Execution Payload\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Execution Payload\",\n \"lineHeight\": 1.25\n },\n {\n \"id\": \"TJdFCkbobxr71YBZ3zIY3\",\n \"type\": \"arrow\",\n \"x\": 2878.5446794424574,\n \"y\": 271.20877586768097,\n \"width\": 189.99999999999955,\n \"height\": 17.5,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b4c\",\n \"roundness\": {\n \"type\": 2\n },\n \"seed\": 634064267,\n \"version\": 48,\n \"versionNonce\": 36858917,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713875457484,\n \"link\": null,\n \"locked\": false,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 189.99999999999955,\n 17.5\n ]\n ],\n \"lastCommittedPoint\": null,\n \"startBinding\": {\n \"elementId\": \"1oLAKeS_wwmO2k3mok9uB\",\n \"focus\": -0.1509456559597161,\n \"gap\": 1\n },\n \"endBinding\": {\n \"elementId\": \"sXIAKri50_wjoyQFouAmw\",\n \"focus\": -0.6469085050830515,\n \"gap\": 5.000000000000227\n },\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\"\n },\n {\n \"id\": \"P7evjmexObVpa2rwRD3uK\",\n \"type\": \"arrow\",\n \"x\": 1207.3980552296318,\n \"y\": -1146.2912241323188,\n \"width\": 630.747328019758,\n \"height\": 662.4999999999998,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b4i\",\n \"roundness\": {\n \"type\": 2\n },\n \"seed\": 1105511045,\n \"version\": 453,\n \"versionNonce\": 338511205,\n \"isDeleted\": false,\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"jiqzrTyPxKTSZeKTidz1F\"\n }\n ],\n \"updated\": 1713875775993,\n \"link\": null,\n \"locked\": false,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 616.1466242128256,\n 275\n ],\n [\n 630.747328019758,\n 662.4999999999998\n ]\n ],\n \"lastCommittedPoint\": null,\n \"startBinding\": {\n \"elementId\": \"pdfHKWOVjyBT3Vc5l1g3l\",\n \"focus\": 0.21969876573594227,\n \"gap\": 25\n },\n \"endBinding\": {\n \"elementId\": \"AXWnLBcYhxyE2YlZC1TEK\",\n \"focus\": -0.42617918596262333,\n \"gap\": 22.5\n },\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\"\n },\n {\n \"id\": \"jiqzrTyPxKTSZeKTidz1F\",\n \"type\": \"text\",\n \"x\": 1694.144685545973,\n \"y\": -725.0412241323189,\n \"width\": 356.29998779296875,\n \"height\": 45,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b4j\",\n \"roundness\": null,\n \"seed\": 1673141131,\n \"version\": 24,\n \"versionNonce\": 2138417803,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713875608149,\n \"link\": null,\n \"locked\": false,\n \"text\": \"Get this PayloadID\",\n \"fontSize\": 36,\n \"fontFamily\": 1,\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"P7evjmexObVpa2rwRD3uK\",\n \"originalText\": \"Get this PayloadID\",\n \"lineHeight\": 1.25\n },\n {\n \"id\": \"pdfHKWOVjyBT3Vc5l1g3l\",\n \"type\": \"rectangle\",\n \"x\": 896.0446794424579,\n \"y\": -1293.7912241323188,\n \"width\": 380.0000000000001,\n \"height\": 122.49999999999997,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b4k\",\n \"roundness\": {\n \"type\": 3\n },\n \"seed\": 246334411,\n \"version\": 306,\n \"versionNonce\": 1026936933,\n \"isDeleted\": false,\n \"boundElements\": [\n {\n \"id\": \"P7evjmexObVpa2rwRD3uK\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"CNDvd5iNr4Xo5en7u4Jre\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713875778592,\n \"link\": null,\n \"locked\": false\n },\n {\n \"id\": \"ZUk6JD_fLxqGankUT_ZRZ\",\n \"type\": \"text\",\n \"x\": 943.5446794424579,\n \"y\": -1261.2912241323188,\n \"width\": 279.1166687011719,\n \"height\": 45,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b4m\",\n \"roundness\": null,\n \"seed\": 2099047371,\n \"version\": 239,\n \"versionNonce\": 1960932613,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713875740861,\n \"link\": null,\n \"locked\": false,\n \"text\": \"Consensus layer\",\n \"fontSize\": 36,\n \"fontFamily\": 1,\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Consensus layer\",\n \"lineHeight\": 1.25\n },\n {\n \"id\": \"AXWnLBcYhxyE2YlZC1TEK\",\n \"type\": \"rectangle\",\n \"x\": 1711.0446794424574,\n \"y\": -461.29122413231903,\n \"width\": 459.99999999999994,\n \"height\": 149.99999999999997,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b4n\",\n \"roundness\": {\n \"type\": 3\n },\n \"seed\": 465656555,\n \"version\": 67,\n \"versionNonce\": 789386635,\n \"isDeleted\": false,\n \"boundElements\": [\n {\n \"id\": \"P7evjmexObVpa2rwRD3uK\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713875697975,\n \"link\": null,\n \"locked\": false\n },\n {\n \"id\": \"SpaW6pikXMsnMTpPEknbB\",\n \"type\": \"text\",\n \"x\": 1746.0446794424574,\n \"y\": -406.29122413231903,\n \"width\": 381.7166748046875,\n \"height\": 45,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b4o\",\n \"roundness\": null,\n \"seed\": 1661539525,\n \"version\": 38,\n \"versionNonce\": 2005903621,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713875695131,\n \"link\": null,\n \"locked\": false,\n \"text\": \"Stop Payload Building\",\n \"fontSize\": 36,\n \"fontFamily\": 1,\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Stop Payload Building\",\n \"lineHeight\": 1.25\n },\n {\n \"id\": \"CNDvd5iNr4Xo5en7u4Jre\",\n \"type\": \"arrow\",\n \"x\": -38.95532055754188,\n \"y\": 218.70877586768074,\n \"width\": 969.9999999999998,\n \"height\": 1359.9999999999995,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b4p\",\n \"roundness\": {\n \"type\": 2\n },\n \"seed\": 1289034923,\n \"version\": 302,\n \"versionNonce\": 1668415627,\n \"isDeleted\": false,\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"6K-Nf4nI3G940mwygnF8P\"\n }\n ],\n \"updated\": 1713875789067,\n \"link\": null,\n \"locked\": false,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 12.5,\n -599.9999999999998\n ],\n [\n 802.4999999999998,\n -697.4999999999998\n ],\n [\n 969.9999999999998,\n -1359.9999999999995\n ]\n ],\n \"lastCommittedPoint\": null,\n \"startBinding\": {\n \"elementId\": \"Kzkmeiz0aCo2d_h6zoGgK\",\n \"focus\": -0.020173901740142088,\n \"gap\": 5.964285714285666\n },\n \"endBinding\": {\n \"elementId\": \"pdfHKWOVjyBT3Vc5l1g3l\",\n \"focus\": 0.6420356724743472,\n \"gap\": 30\n },\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\"\n },\n {\n \"id\": \"6K-Nf4nI3G940mwygnF8P\",\n \"type\": \"text\",\n \"x\": 116.45903247900861,\n \"y\": -447.9183587345832,\n \"width\": 523.8833618164062,\n \"height\": 45,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b4pG\",\n \"roundness\": null,\n \"seed\": 1802334565,\n \"version\": 4,\n \"versionNonce\": 307959525,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713875785126,\n \"link\": null,\n \"locked\": false,\n \"text\": \"Send back as response to CL\",\n \"fontSize\": 36,\n \"fontFamily\": 1,\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"CNDvd5iNr4Xo5en7u4Jre\",\n \"originalText\": \"Send back as response to CL\",\n \"lineHeight\": 1.25\n }\n ],\n \"appState\": {\n \"gridSize\": null,\n \"viewBackgroundColor\": \"#ffffff\"\n },\n \"files\": {}\n}" }, { "path": "docs/images/el-architecture/excalidraw/payload-validation-routine.excalidraw", "content": "{\n \"type\": \"excalidraw\",\n \"version\": 2,\n \"source\": \"https://excalidraw.com\",\n \"elements\": [\n {\n \"id\": \"hyKAPZVt_Zp-ozEl1eyVn\",\n \"type\": \"rectangle\",\n \"x\": 132.0943953322386,\n \"y\": -977.5174146085101,\n \"width\": 1022.2304147465442,\n \"height\": 776.2857142857143,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b2V\",\n \"roundness\": {\n \"type\": 3\n },\n \"seed\": 830291915,\n \"version\": 454,\n \"versionNonce\": 2069878763,\n \"isDeleted\": false,\n \"boundElements\": [\n {\n \"id\": \"mEfl5dCAcxvi8joJILrdH\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"MBxU38OnAfoyAvt94-_Fx\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713865518585,\n \"link\": null,\n \"locked\": false\n },\n {\n \"id\": \"QGLluctSqVV0hXwR9a4YO\",\n \"type\": \"text\",\n \"x\": 205.65404714995498,\n \"y\": -950.2096829136817,\n \"width\": 244.21665954589844,\n \"height\": 38.156682027649765,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b2W\",\n \"roundness\": null,\n \"seed\": 48618955,\n \"version\": 245,\n \"versionNonce\": 1950715051,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713866148872,\n \"link\": null,\n \"locked\": false,\n \"text\": \"Block Level STF\",\n \"fontSize\": 30.525345622119815,\n \"fontFamily\": 1,\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Block Level STF\",\n \"lineHeight\": 1.25\n },\n {\n \"id\": \"ndPEcW7XKgBInMRvTfsBc\",\n \"type\": \"rectangle\",\n \"x\": 588.6217890854389,\n \"y\": -837.2757351410243,\n \"width\": 332.5345622119816,\n \"height\": 94.1198156682028,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b2X\",\n \"roundness\": {\n \"type\": 3\n },\n \"seed\": 621323211,\n \"version\": 583,\n \"versionNonce\": 1628430085,\n \"isDeleted\": false,\n \"boundElements\": [\n {\n \"id\": \"tIb-ymU8SQ3MLLwR22-px\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713866063540,\n \"link\": null,\n \"locked\": false\n },\n {\n \"id\": \"Y49uM4-ayzVgp3L7C0QLU\",\n \"type\": \"text\",\n \"x\": 625.534231481752,\n \"y\": -797.3771176295037,\n \"width\": 263.6166687011719,\n \"height\": 29.67741935483871,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b2Y\",\n \"roundness\": null,\n \"seed\": 1295883013,\n \"version\": 386,\n \"versionNonce\": 1893671205,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713866063541,\n \"link\": null,\n \"locked\": false,\n \"text\": \"1. Verify Block Headers\",\n \"fontSize\": 23.741935483870968,\n \"fontFamily\": 1,\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"1. Verify Block Headers\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 655,\n \"versionNonce\": 1694864683,\n \"index\": \"b2a\",\n \"isDeleted\": false,\n \"id\": \"HP-LLyKqbcvLEDK342MIR\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 590.066745562654,\n \"y\": -690.6531032925859,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 326.8202764976958,\n \"height\": 134.59600614439327,\n \"seed\": 945664907,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"5VOuraf5ydTxd0Wh5OR9B\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713866135773,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 402,\n \"versionNonce\": 1494647051,\n \"index\": \"b2b\",\n \"isDeleted\": false,\n \"id\": \"ntQB-Jb2GYrz_EcXfjeVD\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 608.7211234428382,\n \"y\": -623.9874606914595,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 293.1166687011719,\n \"height\": 29.67741935483871,\n \"seed\": 1360333355,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713866135773,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 23.741935483870968,\n \"fontFamily\": 1,\n \"text\": \"2b. Execute Transaction\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"2b. Execute Transaction\",\n \"lineHeight\": 1.25\n },\n {\n \"id\": \"gV2Y0pphGDmLdgjY2mXD_\",\n \"type\": \"rectangle\",\n \"x\": -238.24661849264612,\n \"y\": -503.6602717513672,\n \"width\": 246,\n \"height\": 217.00000000000003,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b2c\",\n \"roundness\": {\n \"type\": 3\n },\n \"seed\": 444370789,\n \"version\": 675,\n \"versionNonce\": 602248773,\n \"isDeleted\": false,\n \"boundElements\": [\n {\n \"id\": \"vUCwt2LLG5qxM_1lCAhDo\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713864523554,\n \"link\": null,\n \"locked\": false\n },\n {\n \"id\": \"UaCoXIaizV55iXD3mjjae\",\n \"type\": \"text\",\n \"x\": -189.24661849264612,\n \"y\": -481.6602717513672,\n \"width\": 138.5500030517578,\n \"height\": 50,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b2d\",\n \"roundness\": null,\n \"seed\": 1779647621,\n \"version\": 678,\n \"versionNonce\": 1048649829,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713864523554,\n \"link\": null,\n \"locked\": false,\n \"text\": \"RLP Encoded\\n Transactions\",\n \"fontSize\": 20,\n \"fontFamily\": 1,\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"RLP Encoded\\n Transactions\",\n \"lineHeight\": 1.25\n },\n {\n \"id\": \"m6mBKdUnpravoO6gR6Jkt\",\n \"type\": \"line\",\n \"x\": -237.24661849264612,\n \"y\": -412.6602717513672,\n \"width\": 246,\n \"height\": 0,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b2g\",\n \"roundness\": {\n \"type\": 2\n },\n \"seed\": 589031339,\n \"version\": 662,\n \"versionNonce\": 1554631621,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713864523554,\n \"link\": null,\n \"locked\": false,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 246,\n 0\n ]\n ],\n \"lastCommittedPoint\": null,\n \"startBinding\": null,\n \"endBinding\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null\n },\n {\n \"id\": \"Zl8UX2zqj-idUOE1v1Lzm\",\n \"type\": \"text\",\n \"x\": -202.24661849264612,\n \"y\": -392.6602717513672,\n \"width\": 44.86666488647461,\n \"height\": 100,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b2i\",\n \"roundness\": null,\n \"seed\": 1662617131,\n \"version\": 523,\n \"versionNonce\": 996543269,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713864523554,\n \"link\": null,\n \"locked\": false,\n \"text\": \"Tx-1\\n.\\n.\\nTx-n\",\n \"fontSize\": 20,\n \"fontFamily\": 1,\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Tx-1\\n.\\n.\\nTx-n\",\n \"lineHeight\": 1.25\n },\n {\n \"id\": \"Oi99Shq8bwzVk-s52hbeU\",\n \"type\": \"rectangle\",\n \"x\": 213.48610040136305,\n \"y\": -682.337691106206,\n \"width\": 127.1889400921659,\n \"height\": 61.89861751152074,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b2j\",\n \"roundness\": {\n \"type\": 3\n },\n \"seed\": 620134763,\n \"version\": 239,\n \"versionNonce\": 963597419,\n \"isDeleted\": false,\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"Yw54JrYSKUXxppK8lbEIy\"\n },\n {\n \"id\": \"vUCwt2LLG5qxM_1lCAhDo\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"5VOuraf5ydTxd0Wh5OR9B\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713863864742,\n \"link\": null,\n \"locked\": false\n },\n {\n \"id\": \"Yw54JrYSKUXxppK8lbEIy\",\n \"type\": \"text\",\n \"x\": 227.16390250921359,\n \"y\": -672.5865390324733,\n \"width\": 99.83333587646484,\n \"height\": 42.3963133640553,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b2k\",\n \"roundness\": null,\n \"seed\": 1031055717,\n \"version\": 317,\n \"versionNonce\": 83857163,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713863864742,\n \"link\": null,\n \"locked\": false,\n \"text\": \"Decode \\nTransaction\",\n \"fontSize\": 16.95852534562212,\n \"fontFamily\": 1,\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"Oi99Shq8bwzVk-s52hbeU\",\n \"originalText\": \"Decode Transaction\",\n \"lineHeight\": 1.25\n },\n {\n \"id\": \"vUCwt2LLG5qxM_1lCAhDo\",\n \"type\": \"arrow\",\n \"x\": 17.753381507353907,\n \"y\": -396.3571512059983,\n \"width\": 232.44698136845406,\n \"height\": 220.34920349467768,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b2l\",\n \"roundness\": {\n \"type\": 2\n },\n \"seed\": 2141034853,\n \"version\": 848,\n \"versionNonce\": 818841861,\n \"isDeleted\": false,\n \"boundElements\": [],\n \"updated\": 1713864523554,\n \"link\": null,\n \"locked\": false,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 232.44698136845406,\n -220.34920349467768\n ]\n ],\n \"lastCommittedPoint\": null,\n \"startBinding\": {\n \"elementId\": \"gV2Y0pphGDmLdgjY2mXD_\",\n \"focus\": 0.5531309508183027,\n \"gap\": 10.000000000000028\n },\n \"endBinding\": {\n \"elementId\": \"Oi99Shq8bwzVk-s52hbeU\",\n \"focus\": -0.10084848543184767,\n \"gap\": 3.7327188940091673\n },\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\"\n },\n {\n \"id\": \"5VOuraf5ydTxd0Wh5OR9B\",\n \"type\": \"arrow\",\n \"x\": 345.32481007878255,\n \"y\": -646.5174146085101,\n \"width\": 243.74193548387143,\n \"height\": 100,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b2n\",\n \"roundness\": {\n \"type\": 2\n },\n \"seed\": 586115083,\n \"version\": 407,\n \"versionNonce\": 1016015723,\n \"isDeleted\": false,\n \"boundElements\": [],\n \"updated\": 1713866136269,\n \"link\": null,\n \"locked\": false,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 126,\n 3\n ],\n [\n 137,\n 100\n ],\n [\n 243.74193548387143,\n 69.4800246712316\n ]\n ],\n \"lastCommittedPoint\": null,\n \"startBinding\": {\n \"elementId\": \"Oi99Shq8bwzVk-s52hbeU\",\n \"gap\": 4.64976958525358,\n \"focus\": 0.09999256435215227\n },\n \"endBinding\": {\n \"elementId\": \"HP-LLyKqbcvLEDK342MIR\",\n \"gap\": 1,\n \"focus\": 0.006059697461334969\n },\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\"\n },\n {\n \"id\": \"jWb2T3fCwkij29ZlP0BWz\",\n \"type\": \"rectangle\",\n \"x\": -844.3894756355032,\n \"y\": -1128.3745574656527,\n \"width\": 309,\n \"height\": 595,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b2p\",\n \"roundness\": {\n \"type\": 3\n },\n \"seed\": 478962891,\n \"version\": 176,\n \"versionNonce\": 316442981,\n \"isDeleted\": false,\n \"boundElements\": [\n {\n \"id\": \"EY_5UVYYOR5rt2vluj2AO\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713864707345,\n \"link\": null,\n \"locked\": false\n },\n {\n \"id\": \"k4g6_US5onQ29XgawnM04\",\n \"type\": \"text\",\n \"x\": -774.3894756355032,\n \"y\": -1028.3745574656527,\n \"width\": 151.38333129882812,\n \"height\": 500,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b2q\",\n \"roundness\": null,\n \"seed\": 1239737323,\n \"version\": 109,\n \"versionNonce\": 950667787,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713864687581,\n \"link\": null,\n \"locked\": false,\n \"text\": \"parentHash\\nfeeRecipient\\nlogsBloom\\nprevRandao\\nblockNumber\\ngasLimit\\ngasUsed\\ntimestamp\\nextraData\\nbaseFeePerGas\\nblobGasUsed\\nexcessBlobGas\\nblockHash\\n\\ntransactions\\n\\nwithdrawals\\nstateRoot\\nreceiptsRoot\\n\",\n \"fontSize\": 20,\n \"fontFamily\": 1,\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"parentHash\\nfeeRecipient\\nlogsBloom\\nprevRandao\\nblockNumber\\ngasLimit\\ngasUsed\\ntimestamp\\nextraData\\nbaseFeePerGas\\nblobGasUsed\\nexcessBlobGas\\nblockHash\\n\\ntransactions\\n\\nwithdrawals\\nstateRoot\\nreceiptsRoot\\n\",\n \"lineHeight\": 1.25\n },\n {\n \"id\": \"RUGNxN3EwKK_b-QrOBlBN\",\n \"type\": \"text\",\n \"x\": -810.3894756355032,\n \"y\": -1105.3745574656527,\n \"width\": 180.14999389648438,\n \"height\": 25,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b2r\",\n \"roundness\": null,\n \"seed\": 1251422443,\n \"version\": 105,\n \"versionNonce\": 1653772459,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713864687581,\n \"link\": null,\n \"locked\": false,\n \"text\": \"Execution Payload\",\n \"fontSize\": 20,\n \"fontFamily\": 1,\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Execution Payload\",\n \"lineHeight\": 1.25\n },\n {\n \"id\": \"Y_VjxKkwr7MywMVVXZk6J\",\n \"type\": \"rectangle\",\n \"x\": -267.2466184926461,\n \"y\": -758.6602717513672,\n \"width\": 300,\n \"height\": 707,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b2s\",\n \"roundness\": {\n \"type\": 3\n },\n \"seed\": 1088895493,\n \"version\": 188,\n \"versionNonce\": 619237195,\n \"isDeleted\": false,\n \"boundElements\": [\n {\n \"id\": \"tIb-ymU8SQ3MLLwR22-px\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"LjDHdgkP5hbqzAg1bEtr7\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"GkXZTrXeaQJn9fK7BDk4b\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"EY_5UVYYOR5rt2vluj2AO\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713864724437,\n \"link\": null,\n \"locked\": false\n },\n {\n \"id\": \"cJa0hdFM64Gs_OcTaPGdV\",\n \"type\": \"text\",\n \"x\": -238.81804706407468,\n \"y\": -734.2317003227957,\n \"width\": 199.71665954589844,\n \"height\": 25,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b2t\",\n \"roundness\": null,\n \"seed\": 339140933,\n \"version\": 83,\n \"versionNonce\": 787720421,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713864564211,\n \"link\": null,\n \"locked\": false,\n \"text\": \"Ancestor of payload\",\n \"fontSize\": 20,\n \"fontFamily\": 1,\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Ancestor of payload\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"text\",\n \"version\": 181,\n \"versionNonce\": 2007550341,\n \"index\": \"b2u\",\n \"isDeleted\": false,\n \"id\": \"HAnU4AFaJYfrHLiZDHkBP\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -214.93828414206018,\n \"y\": -686.6602717513672,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 108.46666717529297,\n \"height\": 225,\n \"seed\": 152412709,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713864523555,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 20,\n \"fontFamily\": 1,\n \"text\": \"parentHash\\n.\\n.\\nblockHash\\n\\n\\n\\n\\n\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"parentHash\\n.\\n.\\nblockHash\\n\\n\\n\\n\\n\",\n \"lineHeight\": 1.25\n },\n {\n \"id\": \"wiFY1hU7nZClxr7QcDDTA\",\n \"type\": \"text\",\n \"x\": -225.24661849264612,\n \"y\": -211.6602717513672,\n \"width\": 163.60000610351562,\n \"height\": 99,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b2v\",\n \"roundness\": null,\n \"seed\": 1212696453,\n \"version\": 77,\n \"versionNonce\": 103229317,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713866148873,\n \"link\": null,\n \"locked\": false,\n \"text\": \"withdrawals\\nstateRoot\\nreceiptsRoot\",\n \"fontSize\": 26.4,\n \"fontFamily\": 1,\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"withdrawals\\nstateRoot\\nreceiptsRoot\",\n \"lineHeight\": 1.25\n },\n {\n \"id\": \"bsz1hchpOrxy0s3QrRZPU\",\n \"type\": \"rectangle\",\n \"x\": 580.3248100787823,\n \"y\": -515.0174146085097,\n \"width\": 322.85714285714266,\n \"height\": 88.57142857142856,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b2w\",\n \"roundness\": {\n \"type\": 3\n },\n \"seed\": 352331205,\n \"version\": 51,\n \"versionNonce\": 880436395,\n \"isDeleted\": false,\n \"boundElements\": [\n {\n \"id\": \"LjDHdgkP5hbqzAg1bEtr7\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713864463334,\n \"link\": null,\n \"locked\": false\n },\n {\n \"id\": \"uV_7bqAB6rj1rAirEVdKk\",\n \"type\": \"text\",\n \"x\": 633.1819529359252,\n \"y\": -480.73170032279575,\n \"width\": 216.81666564941406,\n \"height\": 25,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b2x\",\n \"roundness\": null,\n \"seed\": 1525829925,\n \"version\": 55,\n \"versionNonce\": 1572880325,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713864398447,\n \"link\": null,\n \"locked\": false,\n \"text\": \"3. Process Withdrawls\",\n \"fontSize\": 20,\n \"fontFamily\": 1,\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"3. Process Withdrawls\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 127,\n \"versionNonce\": 1281666053,\n \"index\": \"b2y\",\n \"isDeleted\": false,\n \"id\": \"FWeaD37zl2M3Y6WM2ki7t\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 583.181952935925,\n \"y\": -375.0174146085096,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 322.85714285714266,\n \"height\": 88.57142857142856,\n \"seed\": 1646964197,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"GkXZTrXeaQJn9fK7BDk4b\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713864477130,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 169,\n \"versionNonce\": 1029736331,\n \"index\": \"b2z\",\n \"isDeleted\": false,\n \"id\": \"BhAERZmqGE771P_7jJIXz\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 636.0390957930679,\n \"y\": -340.73170032279563,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 207.6999969482422,\n \"height\": 25,\n \"seed\": 1053141317,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713864492335,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 20,\n \"fontFamily\": 1,\n \"text\": \"4. Verify State Root\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"4. Verify State Root\",\n \"lineHeight\": 1.25\n },\n {\n \"id\": \"tIb-ymU8SQ3MLLwR22-px\",\n \"type\": \"arrow\",\n \"x\": 36.03909579306833,\n \"y\": -692.1846801499082,\n \"width\": 543.0158730158732,\n \"height\": 117.11844874431586,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b30\",\n \"roundness\": {\n \"type\": 2\n },\n \"seed\": 1265614725,\n \"version\": 318,\n \"versionNonce\": 1628283333,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713866063541,\n \"link\": null,\n \"locked\": false,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 208.57142857142867,\n -117.11844874431586\n ],\n [\n 398.57142857142867,\n -55.68987731574441\n ],\n [\n 543.0158730158732,\n -64.21530336778085\n ]\n ],\n \"lastCommittedPoint\": null,\n \"startBinding\": {\n \"elementId\": \"Y_VjxKkwr7MywMVVXZk6J\",\n \"focus\": -0.4590748170179898,\n \"gap\": 3.285714285714448\n },\n \"endBinding\": {\n \"elementId\": \"ndPEcW7XKgBInMRvTfsBc\",\n \"focus\": -0.4121038314763696,\n \"gap\": 9.566820276497367\n },\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\"\n },\n {\n \"id\": \"LjDHdgkP5hbqzAg1bEtr7\",\n \"type\": \"arrow\",\n \"x\": 38.89623865021122,\n \"y\": -234.20812638181752,\n \"width\": 540,\n \"height\": 226.523573940978,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b31\",\n \"roundness\": {\n \"type\": 2\n },\n \"seed\": 1791751435,\n \"version\": 256,\n \"versionNonce\": 396456965,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713864523555,\n \"link\": null,\n \"locked\": false,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 208.57142857142867,\n -189.3807167981209\n ],\n [\n 540,\n -226.523573940978\n ]\n ],\n \"lastCommittedPoint\": null,\n \"startBinding\": {\n \"elementId\": \"Y_VjxKkwr7MywMVVXZk6J\",\n \"focus\": 0.6386139275885225,\n \"gap\": 6.142857142857338\n },\n \"endBinding\": {\n \"elementId\": \"bsz1hchpOrxy0s3QrRZPU\",\n \"focus\": 0.1322803553800593,\n \"gap\": 1.4285714285711038\n },\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\"\n },\n {\n \"id\": \"GkXZTrXeaQJn9fK7BDk4b\",\n \"type\": \"arrow\",\n \"x\": 34.610524364496996,\n \"y\": -175.51050902898876,\n \"width\": 542.8571428571429,\n \"height\": 150.93547700809253,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b32\",\n \"roundness\": {\n \"type\": 2\n },\n \"seed\": 346743205,\n \"version\": 258,\n \"versionNonce\": 1442707141,\n \"isDeleted\": false,\n \"boundElements\": [],\n \"updated\": 1713864523555,\n \"link\": null,\n \"locked\": false,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 264.2857142857142,\n -138.07833415094964\n ],\n [\n 542.8571428571429,\n -150.93547700809253\n ]\n ],\n \"lastCommittedPoint\": null,\n \"startBinding\": {\n \"elementId\": \"Y_VjxKkwr7MywMVVXZk6J\",\n \"focus\": 0.715469231457167,\n \"gap\": 1.857142857143117\n },\n \"endBinding\": {\n \"elementId\": \"FWeaD37zl2M3Y6WM2ki7t\",\n \"focus\": 0.06627017841971537,\n \"gap\": 5.714285714285097\n },\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\"\n },\n {\n \"id\": \"ARQFaM7I7tRh23TW10OhP\",\n \"type\": \"diamond\",\n \"x\": 1310.8962386502114,\n \"y\": -701.5888431799385,\n \"width\": 303.42857142857133,\n \"height\": 290,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b34\",\n \"roundness\": {\n \"type\": 2\n },\n \"seed\": 754464005,\n \"version\": 82,\n \"versionNonce\": 157547915,\n \"isDeleted\": false,\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"wtlubl-kKyAkXT2Vr5Owp\"\n },\n {\n \"id\": \"MBxU38OnAfoyAvt94-_Fx\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"VQsSY2WU4WYDdyYIe2EfR\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"3Rsu2CFC50g9MCJJUvvzc\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713865657591,\n \"link\": null,\n \"locked\": false\n },\n {\n \"id\": \"wtlubl-kKyAkXT2Vr5Owp\",\n \"type\": \"text\",\n \"x\": 1393.4450471567684,\n \"y\": -601.5888431799385,\n \"width\": 138.61666870117188,\n \"height\": 90,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b34V\",\n \"roundness\": null,\n \"seed\": 697087749,\n \"version\": 80,\n \"versionNonce\": 515749867,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713865657591,\n \"link\": null,\n \"locked\": false,\n \"text\": \"Payload\\nValid?\",\n \"fontSize\": 36,\n \"fontFamily\": 1,\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"ARQFaM7I7tRh23TW10OhP\",\n \"originalText\": \"Payload Valid?\",\n \"lineHeight\": 1.25\n },\n {\n \"id\": \"1oLAKeS_wwmO2k3mok9uB\",\n \"type\": \"rectangle\",\n \"x\": -391.10376134978867,\n \"y\": -1295.0174146085099,\n \"width\": 2155.7142857142862,\n \"height\": 1431.1904761904761,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b36\",\n \"roundness\": {\n \"type\": 3\n },\n \"seed\": 1468825605,\n \"version\": 179,\n \"versionNonce\": 1809553515,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713864876307,\n \"link\": null,\n \"locked\": false\n },\n {\n \"id\": \"i744TP7q5bj-L4gf8AiYw\",\n \"type\": \"text\",\n \"x\": -307.38947563550266,\n \"y\": -1259.3031288942243,\n \"width\": 673.5833129882812,\n \"height\": 64.00270956400504,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b39\",\n \"roundness\": null,\n \"seed\": 1269922059,\n \"version\": 59,\n \"versionNonce\": 820297547,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713866148873,\n \"link\": null,\n \"locked\": false,\n \"text\": \"Payload Validation Routine\",\n \"fontSize\": 51.202167651204036,\n \"fontFamily\": 1,\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Payload Validation Routine\",\n \"lineHeight\": 1.25\n },\n {\n \"id\": \"EY_5UVYYOR5rt2vluj2AO\",\n \"type\": \"arrow\",\n \"x\": -526.8180470640741,\n \"y\": -950.7317003227956,\n \"width\": 417.1428571428572,\n \"height\": 297.1428571428569,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b3A\",\n \"roundness\": {\n \"type\": 2\n },\n \"seed\": 1043311333,\n \"version\": 281,\n \"versionNonce\": 1980305099,\n \"isDeleted\": false,\n \"boundElements\": [],\n \"updated\": 1713864802326,\n \"link\": null,\n \"locked\": false,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 377.1428571428572,\n -124.28571428571422\n ],\n [\n 417.1428571428572,\n 172.85714285714266\n ]\n ],\n \"lastCommittedPoint\": null,\n \"startBinding\": {\n \"elementId\": \"jWb2T3fCwkij29ZlP0BWz\",\n \"focus\": -0.18976719697516783,\n \"gap\": 8.571428571429124\n },\n \"endBinding\": {\n \"elementId\": \"Y_VjxKkwr7MywMVVXZk6J\",\n \"focus\": 0.29224918835119207,\n \"gap\": 19.21428571428578\n },\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\"\n },\n {\n \"id\": \"lEWCRi3JyjbAPu4eal_q8\",\n \"type\": \"text\",\n \"x\": -297.38947563550255,\n \"y\": -993.5888431799385,\n \"width\": 393.1666564941406,\n \"height\": 44.095402056095516,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b3C\",\n \"roundness\": null,\n \"seed\": 976942923,\n \"version\": 262,\n \"versionNonce\": 1089685387,\n \"isDeleted\": false,\n \"boundElements\": [],\n \"updated\": 1713865767043,\n \"link\": null,\n \"locked\": false,\n \"text\": \"1. Validate ancestor's \",\n \"fontSize\": 35.27632164487641,\n \"fontFamily\": 1,\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"1. Validate ancestor's \",\n \"lineHeight\": 1.25\n },\n {\n \"id\": \"mEfl5dCAcxvi8joJILrdH\",\n \"type\": \"arrow\",\n \"x\": -154.24661849264555,\n \"y\": -1075.3311204379138,\n \"width\": 923.4285714285714,\n \"height\": 157.96839879918275,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b3D\",\n \"roundness\": {\n \"type\": 2\n },\n \"seed\": 1328741739,\n \"version\": 319,\n \"versionNonce\": 1721132715,\n \"isDeleted\": false,\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"4Kjp1Vo-bTPvvQapiIzkx\"\n }\n ],\n \"updated\": 1713865762225,\n \"link\": null,\n \"locked\": false,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 192.0000000000001,\n -19.81550090904463\n ],\n [\n 840.5714285714286,\n -61.94040725549337\n ],\n [\n 923.4285714285714,\n 96.0279915436894\n ]\n ],\n \"lastCommittedPoint\": null,\n \"startBinding\": null,\n \"endBinding\": {\n \"elementId\": \"hyKAPZVt_Zp-ozEl1eyVn\",\n \"focus\": 0.4624252038835262,\n \"gap\": 1.7857142857142776\n },\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\"\n },\n {\n \"id\": \"4Kjp1Vo-bTPvvQapiIzkx\",\n \"type\": \"text\",\n \"x\": 170.11575901372788,\n \"y\": -1215.9742675501343,\n \"width\": 348.5833435058594,\n \"height\": 45,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b3E\",\n \"roundness\": null,\n \"seed\": 48221541,\n \"version\": 39,\n \"versionNonce\": 67005701,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713864828142,\n \"link\": null,\n \"locked\": false,\n \"text\": \"2. Validate payload\",\n \"fontSize\": 36,\n \"fontFamily\": 1,\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"mEfl5dCAcxvi8joJILrdH\",\n \"originalText\": \"2. Validate payload\",\n \"lineHeight\": 1.25\n },\n {\n \"id\": \"vjXkXpv34nc-Lvp-EfGih\",\n \"type\": \"rectangle\",\n \"x\": 2099.1343338883066,\n \"y\": -1259.1840812751761,\n \"width\": 423.7168141592923,\n \"height\": 506.66666666666674,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b3F\",\n \"roundness\": {\n \"type\": 3\n },\n \"seed\": 2107078437,\n \"version\": 248,\n \"versionNonce\": 534016229,\n \"isDeleted\": false,\n \"boundElements\": [\n {\n \"id\": \"3Rsu2CFC50g9MCJJUvvzc\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713865727315,\n \"link\": null,\n \"locked\": false\n },\n {\n \"id\": \"9O29z6dnVUNBWwc5x4zvf\",\n \"type\": \"rectangle\",\n \"x\": 2175.5134594346478,\n \"y\": -1182.1300418305514,\n \"width\": 293.8698891804579,\n \"height\": 124.15433302585227,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b3K\",\n \"roundness\": {\n \"type\": 3\n },\n \"seed\": 529091819,\n \"version\": 345,\n \"versionNonce\": 1944026411,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713865727316,\n \"link\": null,\n \"locked\": false\n },\n {\n \"id\": \"DWGdPmwOKPIuDXF66iQxM\",\n \"type\": \"text\",\n \"x\": 2181.2086123257413,\n \"y\": -1175.2958583612385,\n \"width\": 86.46666717529297,\n \"height\": 30.75382561190837,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b3L\",\n \"roundness\": null,\n \"seed\": 533025189,\n \"version\": 347,\n \"versionNonce\": 1279389413,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713866148873,\n \"link\": null,\n \"locked\": false,\n \"text\": \"Status\",\n \"fontSize\": 24.603060489526694,\n \"fontFamily\": 1,\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Status\",\n \"lineHeight\": 1.25\n },\n {\n \"id\": \"oAyO93rZpaqRqxJ85rCrx\",\n \"type\": \"text\",\n \"x\": 2288.2774866783116,\n \"y\": -1128.876531478491,\n \"width\": 91,\n \"height\": 36.729905327226845,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b3O\",\n \"roundness\": null,\n \"seed\": 285656619,\n \"version\": 248,\n \"versionNonce\": 71605739,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713866148873,\n \"link\": null,\n \"locked\": false,\n \"text\": \"VALID\",\n \"fontSize\": 29.383924261781477,\n \"fontFamily\": 1,\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"VALID\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 462,\n \"versionNonce\": 175972581,\n \"index\": \"b3P\",\n \"isDeleted\": false,\n \"id\": \"2fvNeMpUoZKVTyFL7X2br\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 2155.411722453281,\n \"y\": -990.4814505571169,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 318.8058096311372,\n \"height\": 170.29846441994889,\n \"seed\": 893700171,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [],\n \"updated\": 1713865825362,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 495,\n \"versionNonce\": 868163269,\n \"index\": \"b3Q\",\n \"isDeleted\": false,\n \"id\": \"4zt203vEzjPh0BWVqmics\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 2169.6548295919256,\n \"y\": -980.4891391421165,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 208.68333435058594,\n \"height\": 29.06095447730791,\n \"seed\": 1908115179,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713865847540,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 23.248763581846326,\n \"fontFamily\": 1,\n \"text\": \"Latest Valid Hash\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Latest Valid Hash\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"text\",\n \"version\": 442,\n \"versionNonce\": 1171944773,\n \"index\": \"b3R\",\n \"isDeleted\": false,\n \"id\": \"yjnY7c7lVTejjPbEh2LtB\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 2177.799324821216,\n \"y\": -906.9021067606291,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 276.1666564941406,\n \"height\": 34.70807567618682,\n \"seed\": 2049012107,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713866412246,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 27.76646054094946,\n \"fontFamily\": 1,\n \"text\": \"Payload's BlockHash\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Payload's BlockHash\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 431,\n \"versionNonce\": 1048645099,\n \"index\": \"b3S\",\n \"isDeleted\": false,\n \"id\": \"hn1ro19dBW9cixmJ2BASK\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 2087.917519729014,\n \"y\": -424.18408127517625,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 447.13274336283206,\n \"height\": 534.6666666666666,\n \"seed\": 530533285,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"VQsSY2WU4WYDdyYIe2EfR\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713865721788,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"rectangle\",\n \"version\": 519,\n \"versionNonce\": 949439749,\n \"index\": \"b3T\",\n \"isDeleted\": false,\n \"id\": \"KbDXNWO-EB3sqLVXlXKCq\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 2160.119691191122,\n \"y\": -332.794305371301,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 333.7387202891166,\n \"height\": 140.9981415174949,\n \"seed\": 660639493,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [],\n \"updated\": 1713865721790,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 521,\n \"versionNonce\": 1179437637,\n \"index\": \"b3U\",\n \"isDeleted\": false,\n \"id\": \"ak7HOx8cLqCChVdArWzwH\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 2166.587495847888,\n \"y\": -325.0329397831821,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 98.21666717529297,\n \"height\": 34.92614514653544,\n \"seed\": 1625450085,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713866148873,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 27.94091611722835,\n \"fontFamily\": 1,\n \"text\": \"Status\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Status\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"text\",\n \"version\": 442,\n \"versionNonce\": 695183499,\n \"index\": \"b3V\",\n \"isDeleted\": false,\n \"id\": \"2BHW_BO-8a21MqRGgI02e\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 2286.345502323971,\n \"y\": -275.9894234315219,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 143,\n \"height\": 41.712989494890564,\n \"seed\": 1861374405,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713866148873,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 33.37039159591245,\n \"fontFamily\": 1,\n \"text\": \"INVALID\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"INVALID\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 600,\n \"versionNonce\": 1055998059,\n \"index\": \"b3W\",\n \"isDeleted\": false,\n \"id\": \"GUpY2vMiABRQir7C1HzwO\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 2154.3981562476474,\n \"y\": -137.52255908950565,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 349.9167626689994,\n \"height\": 162.62457798576042,\n \"seed\": 1051578661,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [],\n \"updated\": 1713865721790,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 614,\n \"versionNonce\": 623196581,\n \"index\": \"b3X\",\n \"isDeleted\": false,\n \"id\": \"GBRm8hQf9GXKSzR7LHcpR\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 2169.1897180457045,\n \"y\": -126.35061262750764,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 216.76666259765625,\n \"height\": 30.179995128683935,\n \"seed\": 1031955589,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713866148874,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 24.14399610294715,\n \"fontFamily\": 1,\n \"text\": \"Latest Valid Hash\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Latest Valid Hash\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"text\",\n \"version\": 585,\n \"versionNonce\": 1399269675,\n \"index\": \"b3Y\",\n \"isDeleted\": false,\n \"id\": \"yzvNvxosnmtneHkhYMyen\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 2175.570817339364,\n \"y\": -62.392068570919776,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 299.75,\n \"height\": 36.04456817312172,\n \"seed\": 1328384997,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713866422896,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 28.835654538497376,\n \"fontFamily\": 1,\n \"text\": \"Last Valid BlockHash\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Last Valid BlockHash\",\n \"lineHeight\": 1.25\n },\n {\n \"id\": \"MBxU38OnAfoyAvt94-_Fx\",\n \"type\": \"arrow\",\n \"x\": 1165.4676672216406,\n \"y\": -563.761066343996,\n \"width\": 144.72879476645903,\n \"height\": 6.457861474740412,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b3Z\",\n \"roundness\": {\n \"type\": 2\n },\n \"seed\": 1511757963,\n \"version\": 77,\n \"versionNonce\": 1499748043,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713865657591,\n \"link\": null,\n \"locked\": false,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 144.72879476645903,\n 6.457861474740412\n ]\n ],\n \"lastCommittedPoint\": null,\n \"startBinding\": {\n \"elementId\": \"hyKAPZVt_Zp-ozEl1eyVn\",\n \"gap\": 11.14285714285785,\n \"focus\": 0.006129345471310307\n },\n \"endBinding\": {\n \"elementId\": \"ARQFaM7I7tRh23TW10OhP\",\n \"gap\": 1.0000000000001137,\n \"focus\": -0.04197530864197869\n },\n \"startArrowhead\": null,\n \"endArrowhead\": null\n },\n {\n \"id\": \"VQsSY2WU4WYDdyYIe2EfR\",\n \"type\": \"arrow\",\n \"x\": 1456.555189171539,\n \"y\": -415.99291894416814,\n \"width\": 646,\n \"height\": 314.9755043356585,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b3c\",\n \"roundness\": {\n \"type\": 2\n },\n \"seed\": 1960846635,\n \"version\": 233,\n \"versionNonce\": 1347799461,\n \"isDeleted\": false,\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"IgtwWwmIhRtx8TFUM5pVU\"\n }\n ],\n \"updated\": 1713865721789,\n \"link\": null,\n \"locked\": false,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -29.087521949898473,\n 314.9755043356585\n ],\n [\n 616.9124780501015,\n 280.9134968443259\n ]\n ],\n \"lastCommittedPoint\": null,\n \"startBinding\": {\n \"elementId\": \"ARQFaM7I7tRh23TW10OhP\",\n \"gap\": 1,\n \"focus\": -0.04566801619433796\n },\n \"endBinding\": {\n \"elementId\": \"hn1ro19dBW9cixmJ2BASK\",\n \"gap\": 14.449852507373862,\n \"focus\": -0.03303690893979622\n },\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\"\n },\n {\n \"id\": \"IgtwWwmIhRtx8TFUM5pVU\",\n \"type\": \"text\",\n \"x\": 1402.8093343969335,\n \"y\": -123.51741460850963,\n \"width\": 49.31666564941406,\n \"height\": 45,\n \"angle\": 0,\n \"strokeColor\": \"#e03131\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b3cV\",\n \"roundness\": null,\n \"seed\": 1920856645,\n \"version\": 5,\n \"versionNonce\": 323282725,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713865618877,\n \"link\": null,\n \"locked\": false,\n \"text\": \"NO\",\n \"fontSize\": 36,\n \"fontFamily\": 1,\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"VQsSY2WU4WYDdyYIe2EfR\",\n \"originalText\": \"NO\",\n \"lineHeight\": 1.25\n },\n {\n \"id\": \"3Rsu2CFC50g9MCJJUvvzc\",\n \"type\": \"arrow\",\n \"x\": 1610.5587071610566,\n \"y\": -551.606139582262,\n \"width\": 492.90896006058347,\n \"height\": 224.24653610932512,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b3e\",\n \"roundness\": {\n \"type\": 2\n },\n \"seed\": 970847333,\n \"version\": 347,\n \"versionNonce\": 2072677227,\n \"isDeleted\": false,\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"FVOMiuf9su9Ng7OaPrPIz\"\n }\n ],\n \"updated\": 1713865864570,\n \"link\": null,\n \"locked\": false,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 254.90896006058392,\n -71.41127502624761\n ],\n [\n 492.90896006058347,\n -224.24653610932512\n ]\n ],\n \"lastCommittedPoint\": null,\n \"startBinding\": {\n \"elementId\": \"ARQFaM7I7tRh23TW10OhP\",\n \"focus\": 0.3202036810177693,\n \"gap\": 1\n },\n \"endBinding\": {\n \"elementId\": \"vjXkXpv34nc-Lvp-EfGih\",\n \"focus\": -0.24842672548335346,\n \"gap\": 1\n },\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\"\n },\n {\n \"id\": \"FVOMiuf9su9Ng7OaPrPIz\",\n \"type\": \"text\",\n \"x\": 1677.101002335166,\n \"y\": -713.5174146085096,\n \"width\": 64.73332977294922,\n \"height\": 45,\n \"angle\": 0,\n \"strokeColor\": \"#2f9e44\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b3eV\",\n \"roundness\": null,\n \"seed\": 283305093,\n \"version\": 6,\n \"versionNonce\": 1138818245,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713865611460,\n \"link\": null,\n \"locked\": false,\n \"text\": \"YES\",\n \"fontSize\": 36,\n \"fontFamily\": 1,\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"3Rsu2CFC50g9MCJJUvvzc\",\n \"originalText\": \"YES\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"text\",\n \"version\": 446,\n \"versionNonce\": 1280845739,\n \"index\": \"b3h\",\n \"isDeleted\": false,\n \"id\": \"cC9bMF2l81IPc8JZ0MON1\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 610.3276149331413,\n \"y\": -667.4831084129132,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 239.13333129882812,\n \"height\": 29.67741935483871,\n \"seed\": 418385509,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713866135773,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 23.741935483870968,\n \"fontFamily\": 1,\n \"text\": \"2a. Sender Recovery\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"2a. Sender Recovery\",\n \"lineHeight\": 1.25\n }\n ],\n \"appState\": {\n \"gridSize\": null,\n \"viewBackgroundColor\": \"#ffffff\"\n },\n \"files\": {}\n}" }, { "path": "docs/images/el-architecture/excalidraw/reth-architecture-overview.excalidraw", "content": "{\n \"type\": \"excalidraw\",\n \"version\": 2,\n \"source\": \"https://excalidraw.com\",\n \"elements\": [\n {\n \"id\": \"ugEhflCPVRMYEchBpgC_z\",\n \"type\": \"rectangle\",\n \"x\": -53.1989994450264,\n \"y\": -1334.29122413232,\n \"width\": 214,\n \"height\": 79.00000000000003,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b1N\",\n \"roundness\": {\n \"type\": 3\n },\n \"seed\": 987569607,\n \"version\": 365,\n \"versionNonce\": 1175255303,\n \"isDeleted\": false,\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"aSZL4m91pjbhlnc22x7Sy\"\n },\n {\n \"id\": \"6jvYc_FjQTcjxtS7wqIQX\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"Rv2duOWgaNWOk0dAhJkkx\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"Xp18PmUgUd1qTZNiswyq5\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"qXoX5GMlhIChFyTGThj2E\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713775792153,\n \"link\": null,\n \"locked\": false\n },\n {\n \"id\": \"aSZL4m91pjbhlnc22x7Sy\",\n \"type\": \"text\",\n \"x\": 13.542665441448207,\n \"y\": -1312.29122413232,\n \"width\": 80.51667022705078,\n \"height\": 35,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b1O\",\n \"roundness\": null,\n \"seed\": 491407081,\n \"version\": 225,\n \"versionNonce\": 961410601,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713775782781,\n \"link\": null,\n \"locked\": false,\n \"text\": \"Engine\",\n \"fontSize\": 28,\n \"fontFamily\": 1,\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"ugEhflCPVRMYEchBpgC_z\",\n \"originalText\": \"Engine\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 446,\n \"versionNonce\": 505939913,\n \"index\": \"b1P\",\n \"isDeleted\": false,\n \"id\": \"PzGNN3dqZDLge7L1CJQCr\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -572.5323327783594,\n \"y\": -819.1245574656535,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 214,\n \"height\": 79.00000000000003,\n \"seed\": 1103551849,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"tPo8ksh5CcJ0aTNHTAlwU\"\n },\n {\n \"id\": \"YFOIoqajCq2BP9u2PAS9n\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"Xp18PmUgUd1qTZNiswyq5\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713776094302,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 324,\n \"versionNonce\": 1430660777,\n \"index\": \"b1Q\",\n \"isDeleted\": false,\n \"id\": \"tPo8ksh5CcJ0aTNHTAlwU\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -565.9573358301172,\n \"y\": -797.1245574656535,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 200.85000610351562,\n \"height\": 35,\n \"seed\": 1975076937,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713776094302,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 28,\n \"fontFamily\": 1,\n \"text\": \"PayloadBuilder\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"PzGNN3dqZDLge7L1CJQCr\",\n \"originalText\": \"PayloadBuilder\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 626,\n \"versionNonce\": 17752297,\n \"index\": \"b1R\",\n \"isDeleted\": false,\n \"id\": \"vZx4VcvB-DG3-1p1CKzGh\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -607.1989994450262,\n \"y\": -168.12455746565377,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 214,\n \"height\": 79.00000000000003,\n \"seed\": 2129085321,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"67HmatngV_5qOSzB8_ra6\"\n },\n {\n \"id\": \"ue3nOy2kaY4kBvASEXt8p\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"YFOIoqajCq2BP9u2PAS9n\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713776107078,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 510,\n \"versionNonce\": 607443913,\n \"index\": \"b1S\",\n \"isDeleted\": false,\n \"id\": \"67HmatngV_5qOSzB8_ra6\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -547.7740002079656,\n \"y\": -146.12455746565377,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 95.1500015258789,\n \"height\": 35,\n \"seed\": 438823529,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713776107078,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 28,\n \"fontFamily\": 1,\n \"text\": \"TxPool\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"vZx4VcvB-DG3-1p1CKzGh\",\n \"originalText\": \"TxPool\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 603,\n \"versionNonce\": 860157031,\n \"index\": \"b1T\",\n \"isDeleted\": false,\n \"id\": \"dXhMdfRC7n3kL_JJvzq2t\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -112.86566611169314,\n \"y\": 135.87544253434623,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 214,\n \"height\": 79.00000000000003,\n \"seed\": 2079432071,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"2mbCW9UylHs3XdQKuzzcD\"\n },\n {\n \"id\": \"g4uzfguo8re24rxhbR8Za\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"ue3nOy2kaY4kBvASEXt8p\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713776032276,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 495,\n \"versionNonce\": 1201131399,\n \"index\": \"b1U\",\n \"isDeleted\": false,\n \"id\": \"2mbCW9UylHs3XdQKuzzcD\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -34.33233328698611,\n \"y\": 157.87544253434623,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 56.93333435058594,\n \"height\": 35,\n \"seed\": 1662145703,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713776032276,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 28,\n \"fontFamily\": 1,\n \"text\": \"P2P\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"dXhMdfRC7n3kL_JJvzq2t\",\n \"originalText\": \"P2P\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 579,\n \"versionNonce\": 1097213831,\n \"index\": \"b1V\",\n \"isDeleted\": false,\n \"id\": \"drSYCn4kA_V7p_Ivnlh7_\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 341.1343338883073,\n \"y\": -198.12455746565377,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 214,\n \"height\": 79.00000000000003,\n \"seed\": 507350153,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"dTAbMlnCGocLw_u_No2r9\"\n },\n {\n \"id\": \"g4uzfguo8re24rxhbR8Za\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"kxLc3P9zGdx_lM-F1S8fc\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"qXoX5GMlhIChFyTGThj2E\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"cbMfMcp7HO5mTxWHwmU9D\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713776413021,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 476,\n \"versionNonce\": 429862313,\n \"index\": \"b1W\",\n \"isDeleted\": false,\n \"id\": \"dTAbMlnCGocLw_u_No2r9\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 371.96766976477215,\n \"y\": -176.12455746565377,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 152.3333282470703,\n \"height\": 35,\n \"seed\": 1775047529,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713775978591,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 28,\n \"fontFamily\": 1,\n \"text\": \"Downloader\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"drSYCn4kA_V7p_Ivnlh7_\",\n \"originalText\": \"Downloader\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 893,\n \"versionNonce\": 2008018791,\n \"index\": \"b1X\",\n \"isDeleted\": false,\n \"id\": \"xds6ZCHn6_m5-gGY7qojh\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 84.46766722164034,\n \"y\": -1036.1245574656537,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 625.6666666666658,\n \"height\": 629,\n \"seed\": 683854567,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"6jvYc_FjQTcjxtS7wqIQX\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"kxLc3P9zGdx_lM-F1S8fc\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"M_b4SRyiVHQ1gtjleTR8v\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"FsupPUKAPFjcl0iK0MzuQ\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"uvtJVhN1H8_GfTfKI7XfX\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713776874241,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"rectangle\",\n \"version\": 794,\n \"versionNonce\": 572077671,\n \"index\": \"b1Z\",\n \"isDeleted\": false,\n \"id\": \"A7ocYMcZLeyJinIXN8scT\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1236.46766722164,\n \"y\": -1042.7912241323202,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 214,\n \"height\": 79.00000000000003,\n \"seed\": 159461705,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"sftYVxyDIKbIcQi5raIlK\"\n },\n {\n \"id\": \"Rv2duOWgaNWOk0dAhJkkx\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"tNSpjo1PohljFEkPRYEFG\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"gDOp3Swc07BycKsrpNQB9\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713776466099,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 716,\n \"versionNonce\": 1826084231,\n \"index\": \"b1a\",\n \"isDeleted\": false,\n \"id\": \"sftYVxyDIKbIcQi5raIlK\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1242.526001572226,\n \"y\": -1020.7912241323202,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 201.88333129882812,\n \"height\": 35,\n \"seed\": 515776553,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713776458955,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 28,\n \"fontFamily\": 1,\n \"text\": \"BlockchainTree\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"A7ocYMcZLeyJinIXN8scT\",\n \"originalText\": \"BlockchainTree\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 799,\n \"versionNonce\": 994738599,\n \"index\": \"b1b\",\n \"isDeleted\": false,\n \"id\": \"k5fUIU8Ean0EHEni9rQjM\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1267.4676672216406,\n \"y\": -372.2197955608916,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 214,\n \"height\": 79.00000000000003,\n \"seed\": 2022232135,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"hdZJ3LFJvIORcRruh5s2t\"\n },\n {\n \"id\": \"tNSpjo1PohljFEkPRYEFG\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"Mp2rr_mjv1K-T-gQkFFtI\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"uvtJVhN1H8_GfTfKI7XfX\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713776874241,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 723,\n \"versionNonce\": 863464167,\n \"index\": \"b1c\",\n \"isDeleted\": false,\n \"id\": \"hdZJ3LFJvIORcRruh5s2t\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1319.4093328710546,\n \"y\": -350.2197955608916,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 110.11666870117188,\n \"height\": 35,\n \"seed\": 330641255,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713776311008,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 28,\n \"fontFamily\": 1,\n \"text\": \"Provider\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"k5fUIU8Ean0EHEni9rQjM\",\n \"originalText\": \"Provider\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 825,\n \"versionNonce\": 525646471,\n \"index\": \"b1d\",\n \"isDeleted\": false,\n \"id\": \"MhnxWS6Mgj7ojTd6m6biB\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1263.4676672216406,\n \"y\": 31.875442534346462,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 214,\n \"height\": 79.00000000000003,\n \"seed\": 1194369767,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"Vr3QsPx0nP1QJ0XUwHdjC\"\n },\n {\n \"id\": \"Mp2rr_mjv1K-T-gQkFFtI\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713776311009,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 781,\n \"versionNonce\": 1175048615,\n \"index\": \"b1e\",\n \"isDeleted\": false,\n \"id\": \"Vr3QsPx0nP1QJ0XUwHdjC\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1301.2510000463476,\n \"y\": 53.87544253434646,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 138.43333435058594,\n \"height\": 35,\n \"seed\": 1862905351,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713776311009,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 28,\n \"fontFamily\": 1,\n \"text\": \"Database\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"MhnxWS6Mgj7ojTd6m6biB\",\n \"originalText\": \"Database\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 801,\n \"versionNonce\": 1178941161,\n \"index\": \"b1f\",\n \"isDeleted\": false,\n \"id\": \"cgGkXX5pFfScV7qrDFhqw\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -735.1989994450258,\n \"y\": -1336.7436050847011,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 214,\n \"height\": 79.00000000000003,\n \"seed\": 4249481,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"zf2hRSqL8-8zs4svQegIG\"\n }\n ],\n \"updated\": 1713775765487,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 689,\n \"versionNonce\": 1546678729,\n \"index\": \"b1g\",\n \"isDeleted\": false,\n \"id\": \"zf2hRSqL8-8zs4svQegIG\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -698.273996393268,\n \"y\": -1314.7436050847011,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 140.14999389648438,\n \"height\": 35,\n \"seed\": 1664024169,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713775765487,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 28,\n \"fontFamily\": 1,\n \"text\": \"JSON-RPC\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"cgGkXX5pFfScV7qrDFhqw\",\n \"originalText\": \"JSON-RPC\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 696,\n \"versionNonce\": 1937065511,\n \"index\": \"b1h\",\n \"isDeleted\": false,\n \"id\": \"gkvvZNVnoG3S4QJeAWfdx\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 933.2295719835452,\n \"y\": -843.6007479418442,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 214,\n \"height\": 79.00000000000003,\n \"seed\": 305220167,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"-Szkc5I-W-S8dYfMQkjRM\"\n },\n {\n \"id\": \"FsupPUKAPFjcl0iK0MzuQ\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"gDOp3Swc07BycKsrpNQB9\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713776569190,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 591,\n \"versionNonce\": 1230498119,\n \"index\": \"b1i\",\n \"isDeleted\": false,\n \"id\": \"-Szkc5I-W-S8dYfMQkjRM\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1003.3379055711916,\n \"y\": -821.6007479418442,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 73.78333282470703,\n \"height\": 35,\n \"seed\": 373188967,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713776569190,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 28,\n \"fontFamily\": 1,\n \"text\": \"REVM\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"gkvvZNVnoG3S4QJeAWfdx\",\n \"originalText\": \"REVM\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 756,\n \"versionNonce\": 883503559,\n \"index\": \"b1j\",\n \"isDeleted\": false,\n \"id\": \"Xb3qksPakSSe2ePMgbvY_\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 784.5629053168784,\n \"y\": -243.55312889422498,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 214,\n \"height\": 79.00000000000003,\n \"seed\": 927066313,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"qF5DikoqhUH1QeBSx1BLy\"\n },\n {\n \"id\": \"M_b4SRyiVHQ1gtjleTR8v\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"cbMfMcp7HO5mTxWHwmU9D\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713776413021,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 662,\n \"versionNonce\": 16185511,\n \"index\": \"b1k\",\n \"isDeleted\": false,\n \"id\": \"qF5DikoqhUH1QeBSx1BLy\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 823.2962350898276,\n \"y\": -221.55312889422498,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 136.53334045410156,\n \"height\": 35,\n \"seed\": 1383851945,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713776370353,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 28,\n \"fontFamily\": 1,\n \"text\": \"Consensus\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"Xb3qksPakSSe2ePMgbvY_\",\n \"originalText\": \"Consensus\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 600,\n \"versionNonce\": 72490439,\n \"index\": \"b1l\",\n \"isDeleted\": false,\n \"id\": \"ulFWmP_Qq40gX3DBHn7_S\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1636.0867148406878,\n \"y\": -659.4102717513682,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 214,\n \"height\": 79.00000000000003,\n \"seed\": 1478998471,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"VUjoygOaHDd6m1y0HfMmW\"\n }\n ],\n \"updated\": 1713776626714,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 515,\n \"versionNonce\": 1140378855,\n \"index\": \"b1m\",\n \"isDeleted\": false,\n \"id\": \"VUjoygOaHDd6m1y0HfMmW\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1693.1117163665667,\n \"y\": -637.4102717513682,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 99.94999694824219,\n \"height\": 35,\n \"seed\": 1119545575,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713776626714,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 28,\n \"fontFamily\": 1,\n \"text\": \"Prunner\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"ulFWmP_Qq40gX3DBHn7_S\",\n \"originalText\": \"Prunner\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 783,\n \"versionNonce\": 709442953,\n \"index\": \"b1n\",\n \"isDeleted\": false,\n \"id\": \"y7B5SErMB4Cp0zI_7ZHbr\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -907.7228089688357,\n \"y\": -985.3150336561297,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 214,\n \"height\": 79.00000000000003,\n \"seed\": 1947225609,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"FkZ4s7qtX-KOi7jDldo7s\"\n }\n ],\n \"updated\": 1713775766979,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 709,\n \"versionNonce\": 993698921,\n \"index\": \"b1o\",\n \"isDeleted\": false,\n \"id\": \"FkZ4s7qtX-KOi7jDldo7s\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -883.7811433194216,\n \"y\": -963.3150336561297,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 166.11666870117188,\n \"height\": 35,\n \"seed\": 1254860009,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1713775766979,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 28,\n \"fontFamily\": 1,\n \"text\": \"Snapshotter\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"y7B5SErMB4Cp0zI_7ZHbr\",\n \"originalText\": \"Snapshotter\",\n \"lineHeight\": 1.25\n },\n {\n \"id\": \"g4uzfguo8re24rxhbR8Za\",\n \"type\": \"arrow\",\n \"x\": 30.49226040710994,\n \"y\": 133.40178285406196,\n \"width\": 385.2021491241376,\n \"height\": 246.69300698638222,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b1p\",\n \"roundness\": {\n \"type\": 2\n },\n \"seed\": 1018351335,\n \"version\": 1095,\n \"versionNonce\": 600399977,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713776044387,\n \"link\": null,\n \"locked\": false,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 267.9754068145309,\n -54.693006986382045\n ],\n [\n 385.2021491241376,\n -246.69300698638222\n ]\n ],\n \"lastCommittedPoint\": null,\n \"startBinding\": {\n \"elementId\": \"dXhMdfRC7n3kL_JJvzq2t\",\n \"focus\": -0.5633195001090704,\n \"gap\": 2.473659680284257\n },\n \"endBinding\": {\n \"elementId\": \"drSYCn4kA_V7p_Ivnlh7_\",\n \"focus\": 0.036314051043969044,\n \"gap\": 5.833333333333499\n },\n \"startArrowhead\": \"arrow\",\n \"endArrowhead\": \"arrow\"\n },\n {\n \"id\": \"ue3nOy2kaY4kBvASEXt8p\",\n \"type\": \"arrow\",\n \"x\": -45.936562762673844,\n \"y\": 125.54210920101295,\n \"width\": 419.5534966395238,\n \"height\": 205.79450196763617,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b1q\",\n \"roundness\": {\n \"type\": 2\n },\n \"seed\": 358148777,\n \"version\": 1076,\n \"versionNonce\": 939314761,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713776113900,\n \"link\": null,\n \"locked\": false,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -286.59577001568596,\n -52.49999999999952\n ],\n [\n -419.5534966395238,\n -205.79450196763617\n ]\n ],\n \"lastCommittedPoint\": null,\n \"startBinding\": {\n \"elementId\": \"dXhMdfRC7n3kL_JJvzq2t\",\n \"focus\": 0.7189914274938157,\n \"gap\": 10.333333333333272\n },\n \"endBinding\": {\n \"elementId\": \"vZx4VcvB-DG3-1p1CKzGh\",\n \"focus\": 0.05129518029556422,\n \"gap\": 8.872164699030535\n },\n \"startArrowhead\": \"arrow\",\n \"endArrowhead\": \"arrow\"\n },\n {\n \"id\": \"Xp18PmUgUd1qTZNiswyq5\",\n \"type\": \"arrow\",\n \"x\": -63.36174551335486,\n \"y\": -1270.6245574656534,\n \"width\": 389.4462731379299,\n \"height\": 442.3333333333329,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b1t\",\n \"roundness\": {\n \"type\": 2\n },\n \"seed\": 142003145,\n \"version\": 796,\n \"versionNonce\": 976344137,\n \"isDeleted\": false,\n \"boundElements\": [],\n \"updated\": 1713776134799,\n \"link\": null,\n \"locked\": false,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -353.69439678881406,\n 92.57142857142844\n ],\n [\n -389.4462731379299,\n 442.3333333333329\n ]\n ],\n \"lastCommittedPoint\": null,\n \"startBinding\": {\n \"elementId\": \"ugEhflCPVRMYEchBpgC_z\",\n \"focus\": 0.09625989714920022,\n \"gap\": 10.16274606832846\n },\n \"endBinding\": {\n \"elementId\": \"PzGNN3dqZDLge7L1CJQCr\",\n \"focus\": 0.06979362553572661,\n \"gap\": 9.16666666666697\n },\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\"\n },\n {\n \"id\": \"YFOIoqajCq2BP9u2PAS9n\",\n \"type\": \"arrow\",\n \"x\": -489.4335012959579,\n \"y\": -728.6245574656537,\n \"width\": 7.528589606812773,\n \"height\": 551.3333333333331,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b1v\",\n \"roundness\": {\n \"type\": 2\n },\n \"seed\": 1142955079,\n \"version\": 703,\n \"versionNonce\": 1496695497,\n \"isDeleted\": false,\n \"boundElements\": [],\n \"updated\": 1713776107097,\n \"link\": null,\n \"locked\": false,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -7.528589606812773,\n 551.3333333333331\n ]\n ],\n \"lastCommittedPoint\": null,\n \"startBinding\": {\n \"elementId\": \"PzGNN3dqZDLge7L1CJQCr\",\n \"focus\": 0.21577917100864905,\n \"gap\": 11.499999999999886\n },\n \"endBinding\": {\n \"elementId\": \"vZx4VcvB-DG3-1p1CKzGh\",\n \"focus\": 0.023920106529875154,\n \"gap\": 9.166666666666742\n },\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\"\n },\n {\n \"id\": \"6jvYc_FjQTcjxtS7wqIQX\",\n \"type\": \"arrow\",\n \"x\": 165.80100055497363,\n \"y\": -1264.9438843452708,\n \"width\": 228.54476443112284,\n \"height\": 217.31932687961694,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b1x\",\n \"roundness\": {\n \"type\": 2\n },\n \"seed\": 858348359,\n \"version\": 1176,\n \"versionNonce\": 1817797097,\n \"isDeleted\": false,\n \"boundElements\": [],\n \"updated\": 1713775913184,\n \"link\": null,\n \"locked\": false,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 227.6190476190479,\n 101.65266021295065\n ],\n [\n 228.54476443112284,\n 217.31932687961694\n ]\n ],\n \"lastCommittedPoint\": null,\n \"startBinding\": {\n \"elementId\": \"ugEhflCPVRMYEchBpgC_z\",\n \"gap\": 5,\n \"focus\": -0.23109140852348375\n },\n \"endBinding\": {\n \"elementId\": \"xds6ZCHn6_m5-gGY7qojh\",\n \"gap\": 11.500000000000227,\n \"focus\": -0.0010976830278835936\n },\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\"\n },\n {\n \"id\": \"kxLc3P9zGdx_lM-F1S8fc\",\n \"type\": \"arrow\",\n \"x\": 418.21876684458323,\n \"y\": -386.6245574656539,\n \"width\": 6.769059294978774,\n \"height\": 181.66666666666686,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b1z\",\n \"roundness\": {\n \"type\": 2\n },\n \"seed\": 764595529,\n \"version\": 1296,\n \"versionNonce\": 414307911,\n \"isDeleted\": false,\n \"boundElements\": [],\n \"updated\": 1713776121929,\n \"link\": null,\n \"locked\": false,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 6.769059294978774,\n 181.66666666666686\n ]\n ],\n \"lastCommittedPoint\": null,\n \"startBinding\": {\n \"elementId\": \"xds6ZCHn6_m5-gGY7qojh\",\n \"focus\": -0.025990829469608435,\n \"gap\": 20.499999999999773\n },\n \"endBinding\": {\n \"elementId\": \"drSYCn4kA_V7p_Ivnlh7_\",\n \"focus\": -0.19747147374525595,\n \"gap\": 6.833333333333243\n },\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\"\n },\n {\n \"id\": \"qXoX5GMlhIChFyTGThj2E\",\n \"type\": \"arrow\",\n \"x\": 39.80100055497337,\n \"y\": -1244.2912241323202,\n \"width\": 410.00323038372153,\n \"height\": 1096.066189015292,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b21\",\n \"roundness\": {\n \"type\": 2\n },\n \"seed\": 1280727273,\n \"version\": 918,\n \"versionNonce\": 184883945,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713775978592,\n \"link\": null,\n \"locked\": false,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -115,\n 747.9999999999999\n ],\n [\n 295.00323038372153,\n 1096.066189015292\n ]\n ],\n \"lastCommittedPoint\": null,\n \"startBinding\": {\n \"elementId\": \"ugEhflCPVRMYEchBpgC_z\",\n \"focus\": 0.05514994945524211,\n \"gap\": 10.999999999999773\n },\n \"endBinding\": {\n \"elementId\": \"drSYCn4kA_V7p_Ivnlh7_\",\n \"focus\": -0.8179580666170948,\n \"gap\": 6.33010294961241\n },\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\"\n },\n {\n \"id\": \"Rv2duOWgaNWOk0dAhJkkx\",\n \"type\": \"arrow\",\n \"x\": 165.08671484068805,\n \"y\": -1309.9141202317337,\n \"width\": 1094.6775963490484,\n \"height\": 266.1228960994133,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b25\",\n \"roundness\": {\n \"type\": 2\n },\n \"seed\": 207962503,\n \"version\": 1022,\n \"versionNonce\": 410297385,\n \"isDeleted\": false,\n \"boundElements\": [],\n \"updated\": 1713776458958,\n \"link\": null,\n \"locked\": false,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 941.4285714285713,\n 58.527658004175464\n ],\n [\n 1094.6775963490484,\n 266.1228960994133\n ]\n ],\n \"lastCommittedPoint\": null,\n \"startBinding\": {\n \"elementId\": \"ugEhflCPVRMYEchBpgC_z\",\n \"focus\": -0.47758227340052595,\n \"gap\": 4.285714285714448\n },\n \"endBinding\": {\n \"elementId\": \"A7ocYMcZLeyJinIXN8scT\",\n \"focus\": -0.395168115813512,\n \"gap\": 1\n },\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\"\n },\n {\n \"id\": \"tNSpjo1PohljFEkPRYEFG\",\n \"type\": \"arrow\",\n \"x\": 1367.378979516352,\n \"y\": -956.1483669894633,\n \"width\": 10.179232304502193,\n \"height\": 580,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b27\",\n \"roundness\": {\n \"type\": 2\n },\n \"seed\": 621145897,\n \"version\": 1161,\n \"versionNonce\": 458649065,\n \"isDeleted\": false,\n \"boundElements\": [],\n \"updated\": 1713776458959,\n \"link\": null,\n \"locked\": false,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 10.179232304502193,\n 580\n ]\n ],\n \"lastCommittedPoint\": null,\n \"startBinding\": {\n \"elementId\": \"A7ocYMcZLeyJinIXN8scT\",\n \"focus\": -0.21434897950918255,\n \"gap\": 7.642857142856997\n },\n \"endBinding\": {\n \"elementId\": \"k5fUIU8Ean0EHEni9rQjM\",\n \"focus\": 0.0357750717932889,\n \"gap\": 3.928571428571672\n },\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\"\n },\n {\n \"id\": \"Mp2rr_mjv1K-T-gQkFFtI\",\n \"type\": \"arrow\",\n \"x\": 1358.1488649434107,\n \"y\": -275.19598603708243,\n \"width\": 15.412720232059428,\n \"height\": 309.40476190476215,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b29\",\n \"roundness\": {\n \"type\": 2\n },\n \"seed\": 1485043271,\n \"version\": 1234,\n \"versionNonce\": 1459919977,\n \"isDeleted\": false,\n \"boundElements\": [],\n \"updated\": 1713776311328,\n \"link\": null,\n \"locked\": false,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 15.412720232059428,\n 309.40476190476215\n ]\n ],\n \"lastCommittedPoint\": null,\n \"startBinding\": {\n \"elementId\": \"k5fUIU8Ean0EHEni9rQjM\",\n \"focus\": 0.17605498451546256,\n \"gap\": 18.023809523809177\n },\n \"endBinding\": {\n \"elementId\": \"MhnxWS6Mgj7ojTd6m6biB\",\n \"focus\": 0.04538357708482443,\n \"gap\": 1\n },\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\"\n },\n {\n \"id\": \"Bggk-jNBp2vqiBy9IkhTB\",\n \"type\": \"rectangle\",\n \"x\": 177.22957198354516,\n \"y\": -941.038494747883,\n \"width\": 451.42857142857116,\n \"height\": 497.8926829268293,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b2B\",\n \"roundness\": {\n \"type\": 3\n },\n \"seed\": 25220711,\n \"version\": 491,\n \"versionNonce\": 1728141575,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713775874751,\n \"link\": null,\n \"locked\": false\n },\n {\n \"id\": \"bKBcFqO613HLXZ2NI58H1\",\n \"type\": \"text\",\n \"x\": 213.90947906833003,\n \"y\": -847.9202601369656,\n \"width\": 375.9333190917969,\n \"height\": 420.8195121951219,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b2D\",\n \"roundness\": null,\n \"seed\": 889451527,\n \"version\": 859,\n \"versionNonce\": 1682326599,\n \"isDeleted\": false,\n \"boundElements\": [\n {\n \"id\": \"kxLc3P9zGdx_lM-F1S8fc\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1713777311522,\n \"link\": null,\n \"locked\": false,\n \"text\": \"1. HeaderStage\\n2. BodyStage\\n3. SenderRecoveryStage\\n4. ExecutionStage\\n5. MerkleStage\\n6. AccountHashingStage\\n7. StorageHashingStage\\n8. MerkleStage\\n9. TransactionLookupStage\\n10. IndexStorageHistoryStage\\n11. IndexAccountHistoryStage\\n12. FinishStage\\n\",\n \"fontSize\": 25.896585365853657,\n \"fontFamily\": 1,\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"1. HeaderStage\\n2. BodyStage\\n3. SenderRecoveryStage\\n4. ExecutionStage\\n5. MerkleStage\\n6. AccountHashingStage\\n7. StorageHashingStage\\n8. MerkleStage\\n9. TransactionLookupStage\\n10. IndexStorageHistoryStage\\n11. IndexAccountHistoryStage\\n12. FinishStage\\n\",\n \"lineHeight\": 1.25\n },\n {\n \"id\": \"owDEE9N-Gu0OdIM5jes1o\",\n \"type\": \"text\",\n \"x\": 210.82655223906113,\n \"y\": -918.8275772101368,\n \"width\": 138.98333740234375,\n \"height\": 41.61951219512194,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b2F\",\n \"roundness\": null,\n \"seed\": 1131489639,\n \"version\": 374,\n \"versionNonce\": 493111209,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713777311522,\n \"link\": null,\n \"locked\": false,\n \"text\": \"Stages :\",\n \"fontSize\": 33.295609756097555,\n \"fontFamily\": 1,\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Stages :\",\n \"lineHeight\": 1.25\n },\n {\n \"id\": \"l5cznvWbRZZgn_z0tDfP9\",\n \"type\": \"text\",\n \"x\": 110.08671484068714,\n \"y\": -1005.4340812751777,\n \"width\": 123,\n \"height\": 45,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b2G\",\n \"roundness\": null,\n \"seed\": 1944918025,\n \"version\": 46,\n \"versionNonce\": 1876297863,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713776026910,\n \"link\": null,\n \"locked\": false,\n \"text\": \"Pipeline\",\n \"fontSize\": 36,\n \"fontFamily\": 1,\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Pipeline\",\n \"lineHeight\": 1.25\n },\n {\n \"id\": \"M_b4SRyiVHQ1gtjleTR8v\",\n \"type\": \"arrow\",\n \"x\": 690.0867148406871,\n \"y\": -405.43408127517773,\n \"width\": 170,\n \"height\": 168.33333333333326,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b2J\",\n \"roundness\": {\n \"type\": 2\n },\n \"seed\": 765064553,\n \"version\": 103,\n \"versionNonce\": 338713031,\n \"isDeleted\": false,\n \"boundElements\": [],\n \"updated\": 1713776396673,\n \"link\": null,\n \"locked\": false,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 138.33333333333348,\n 30\n ],\n [\n 170,\n 168.33333333333326\n ]\n ],\n \"lastCommittedPoint\": null,\n \"startBinding\": {\n \"elementId\": \"xds6ZCHn6_m5-gGY7qojh\",\n \"focus\": 0.6609105757666474,\n \"gap\": 1.6904761904759198\n },\n \"endBinding\": {\n \"elementId\": \"Xb3qksPakSSe2ePMgbvY_\",\n \"focus\": -0.20605503271755274,\n \"gap\": 1\n },\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\"\n },\n {\n \"id\": \"cbMfMcp7HO5mTxWHwmU9D\",\n \"type\": \"arrow\",\n \"x\": 551.7533815073539,\n \"y\": -162.10074794184447,\n \"width\": 226.66666666666652,\n \"height\": 31.666666666666742,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b2L\",\n \"roundness\": {\n \"type\": 2\n },\n \"seed\": 1471927303,\n \"version\": 193,\n \"versionNonce\": 431026311,\n \"isDeleted\": false,\n \"boundElements\": [],\n \"updated\": 1713776413855,\n \"link\": null,\n \"locked\": false,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 123.33333333333326,\n 3.3333333333332575\n ],\n [\n 135,\n -26.666666666666742\n ],\n [\n 226.66666666666652,\n -28.333333333333485\n ]\n ],\n \"lastCommittedPoint\": null,\n \"startBinding\": {\n \"elementId\": \"drSYCn4kA_V7p_Ivnlh7_\",\n \"focus\": -0.14806381589933107,\n \"gap\": 1\n },\n \"endBinding\": {\n \"elementId\": \"Xb3qksPakSSe2ePMgbvY_\",\n \"focus\": -0.2789667742508099,\n \"gap\": 6.14285714285802\n },\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\"\n },\n {\n \"id\": \"FsupPUKAPFjcl0iK0MzuQ\",\n \"type\": \"arrow\",\n \"x\": 725.0867148406871,\n \"y\": -886.4845139302548,\n \"width\": 207.14285714285802,\n \"height\": 71.54313183981503,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b2N\",\n \"roundness\": {\n \"type\": 2\n },\n \"seed\": 470060137,\n \"version\": 482,\n \"versionNonce\": 1154633991,\n \"isDeleted\": false,\n \"boundElements\": [],\n \"updated\": 1713776569393,\n \"link\": null,\n \"locked\": false,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 60,\n 71.05043265507709\n ],\n [\n 207.14285714285802,\n 71.54313183981503\n ]\n ],\n \"lastCommittedPoint\": null,\n \"startBinding\": {\n \"elementId\": \"xds6ZCHn6_m5-gGY7qojh\",\n \"focus\": -0.8073815528124013,\n \"gap\": 14.952380952380963\n },\n \"endBinding\": {\n \"elementId\": \"gkvvZNVnoG3S4QJeAWfdx\",\n \"focus\": 0.26290651965825146,\n \"gap\": 1\n },\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\"\n },\n {\n \"id\": \"gDOp3Swc07BycKsrpNQB9\",\n \"type\": \"arrow\",\n \"x\": 1252.7656470196193,\n \"y\": -962.7912241323202,\n \"width\": 104.53607503607418,\n \"height\": 120.45360101312383,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b2P\",\n \"roundness\": {\n \"type\": 2\n },\n \"seed\": 563536615,\n \"version\": 235,\n \"versionNonce\": 718217031,\n \"isDeleted\": false,\n \"boundElements\": [],\n \"updated\": 1713776574765,\n \"link\": null,\n \"locked\": false,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -26.012265512265685,\n 117.35714285714243\n ],\n [\n -104.53607503607418,\n 120.45360101312383\n ]\n ],\n \"lastCommittedPoint\": null,\n \"startBinding\": {\n \"elementId\": \"A7ocYMcZLeyJinIXN8scT\",\n \"focus\": 0.7060173618114275,\n \"gap\": 1\n },\n \"endBinding\": {\n \"elementId\": \"gkvvZNVnoG3S4QJeAWfdx\",\n \"focus\": -0.7771857517040498,\n \"gap\": 1\n },\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\"\n },\n {\n \"id\": \"uvtJVhN1H8_GfTfKI7XfX\",\n \"type\": \"arrow\",\n \"x\": 716.7533815073539,\n \"y\": -587.1007479418445,\n \"width\": 611.6666666666663,\n \"height\": 208.33333333333326,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b2R\",\n \"roundness\": {\n \"type\": 2\n },\n \"seed\": 1143556295,\n \"version\": 96,\n \"versionNonce\": 322838313,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713776874247,\n \"link\": null,\n \"locked\": false,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 348.33333333333326,\n 3.3333333333333712\n ],\n [\n 611.6666666666663,\n 208.33333333333326\n ]\n ],\n \"lastCommittedPoint\": null,\n \"startBinding\": {\n \"elementId\": \"xds6ZCHn6_m5-gGY7qojh\",\n \"focus\": 0.41407713568803733,\n \"gap\": 6.619047619047706\n },\n \"endBinding\": {\n \"elementId\": \"k5fUIU8Ean0EHEni9rQjM\",\n \"focus\": 0.08306703776242573,\n \"gap\": 6.547619047619605\n },\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\"\n },\n {\n \"id\": \"LdgTRfoMzIZ7j7yiHweWU\",\n \"type\": \"rectangle\",\n \"x\": -1133.2466184926457,\n \"y\": -1677.1007479418436,\n \"width\": 3256.6666666666647,\n \"height\": 2179.9999999999986,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b2S\",\n \"roundness\": {\n \"type\": 3\n },\n \"seed\": 1764388615,\n \"version\": 91,\n \"versionNonce\": 1914107849,\n \"isDeleted\": false,\n \"boundElements\": [],\n \"updated\": 1713777219051,\n \"link\": null,\n \"locked\": false\n },\n {\n \"id\": \"nGbggkxavWyvy0lvRgDwY\",\n \"type\": \"text\",\n \"x\": -1053.2466184926448,\n \"y\": -1570.4340812751766,\n \"width\": 884.7166748046875,\n \"height\": 108.33333333333331,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 0,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"index\": \"b2U\",\n \"roundness\": null,\n \"seed\": 1134444649,\n \"version\": 51,\n \"versionNonce\": 262415207,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1713777311522,\n \"link\": null,\n \"locked\": false,\n \"text\": \"Reth Component Flow\",\n \"fontSize\": 86.66666666666666,\n \"fontFamily\": 1,\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Reth Component Flow\",\n \"lineHeight\": 1.25\n }\n ],\n \"appState\": {\n \"gridSize\": null,\n \"viewBackgroundColor\": \"#ffffff\"\n },\n \"files\": {}\n}" }, { "path": "docs/images/el-specs/excalidraw/gas-header.excalidraw", "content": "{\n \"type\": \"excalidraw\",\n \"version\": 2,\n \"source\": \"https://excalidraw.com\",\n \"elements\": [\n {\n \"type\": \"rectangle\",\n \"version\": 521,\n \"versionNonce\": 1229652653,\n \"isDeleted\": false,\n \"id\": \"fR7kdit369e98Ous3Hvx7\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -355.865666111693,\n \"y\": -655.8864622275578,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 1524,\n \"height\": 1571.0000000000002,\n \"seed\": 276079048,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [],\n \"updated\": 1710200414379,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"rectangle\",\n \"version\": 478,\n \"versionNonce\": 394024755,\n \"isDeleted\": false,\n \"id\": \"za7W4B5dR7ChlMslpX4wu\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -159.19909177974074,\n \"y\": -549.8595262006218,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 222.95622895622898,\n \"height\": 397.973063973064,\n \"seed\": 174240184,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [\n {\n \"id\": \"3zmxeEfb4JTT7GAz8IrZW\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"WioVA79vE4h71iq_2tbfA\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"DXhzqq0zSVnC0CyRzqHKT\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710289465412,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 245,\n \"versionNonce\": 126887181,\n \"isDeleted\": false,\n \"id\": \"eOPzCxEESwotMczLjZlJR\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -107.454984035633,\n \"y\": -603.8864622275578,\n \"strokeColor\": \"#e03131\",\n \"backgroundColor\": \"#ffc9c9\",\n \"width\": 129.73333740234375,\n \"height\": 34.24242424242424,\n \"seed\": 981926856,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710200414379,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 27.393939393939394,\n \"fontFamily\": 1,\n \"text\": \"Gas Limit\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Gas Limit\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"line\",\n \"version\": 268,\n \"versionNonce\": 347749955,\n \"isDeleted\": false,\n \"id\": \"8MhZDySyUUeuVFd3fNDRl\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -158.438149018798,\n \"y\": -354.29723663833215,\n \"strokeColor\": \"#2f9e44\",\n \"backgroundColor\": \"#ffc9c9\",\n \"width\": 224.47811447811452,\n \"height\": 0,\n \"seed\": 68181944,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710200414379,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 224.47811447811452,\n 0\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 278,\n \"versionNonce\": 1579509693,\n \"isDeleted\": false,\n \"id\": \"XXi6eBvtSU3YfHizWP2EH\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -134.84892342957244,\n \"y\": -393.8662602073557,\n \"strokeColor\": \"#2f9e44\",\n \"backgroundColor\": \"#ffc9c9\",\n \"width\": 178.48333740234375,\n \"height\": 34.24242424242424,\n \"seed\": 1589203912,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710289364454,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 27.393939393939394,\n \"fontFamily\": 1,\n \"text\": \"Gas Target \",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Gas Target \",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"text\",\n \"version\": 464,\n \"versionNonce\": 402619875,\n \"isDeleted\": false,\n \"id\": \"Ivjqza_GsSQIWXz1MW9Aq\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -316.5979545617438,\n \"y\": -492.4392650303606,\n \"strokeColor\": \"#e03131\",\n \"backgroundColor\": \"#ffc9c9\",\n \"width\": 106.01667022705078,\n \"height\": 27.995495495495497,\n \"seed\": 1137138872,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710200414379,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 22.396396396396398,\n \"fontFamily\": 1,\n \"text\": \"Gas Limit\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Gas Limit\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"line\",\n \"version\": 519,\n \"versionNonce\": 136971725,\n \"isDeleted\": false,\n \"id\": \"98GxxlcsO_hnI4AO-3JYf\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -316.40653239235155,\n \"y\": -457.55187207241386,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#b2f2bb\",\n \"width\": 100.96595712727728,\n \"height\": 3.238670372605396,\n \"seed\": 854992931,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710200414379,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 100.96595712727728,\n -2.9148033353448572\n ],\n [\n 93.28376473715835,\n -3.238670372605396\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 381,\n \"versionNonce\": 1807468931,\n \"isDeleted\": false,\n \"id\": \"TCLgGARffFN_T2Rs84pA0\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -273.6755514113705,\n \"y\": -454.77785361894917,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#ffc9c9\",\n \"width\": 15.949999809265137,\n \"height\": 27.995495495495497,\n \"seed\": 10356333,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710200414379,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 22.396396396396398,\n \"fontFamily\": 1,\n \"text\": \"2\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"2\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"line\",\n \"version\": 234,\n \"versionNonce\": 1919300627,\n \"isDeleted\": false,\n \"id\": \"su6AT5ZmS_XkqVYc5HJfJ\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -154.865666111693,\n \"y\": -178.88646222755773,\n \"strokeColor\": \"#9c36b5\",\n \"backgroundColor\": \"#ffc9c9\",\n \"width\": 216.00000000000003,\n \"height\": 5,\n \"seed\": 1406890179,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710289354251,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 216.00000000000003,\n -5\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 235,\n \"versionNonce\": 894536179,\n \"isDeleted\": false,\n \"id\": \"2vmEJeyKU7ZmHPTqunJrb\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -145.86566611169297,\n \"y\": -226.88646222755773,\n \"strokeColor\": \"#be4bdb\",\n \"backgroundColor\": \"#ffc9c9\",\n \"width\": 206.14999389648438,\n \"height\": 45,\n \"seed\": 555628461,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [\n {\n \"id\": \"CqnfPKn3XOxytlDa2kd80\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710289357649,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 36,\n \"fontFamily\": 1,\n \"text\": \"Gas used \",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Gas used \",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 1267,\n \"versionNonce\": 1725085325,\n \"isDeleted\": false,\n \"id\": \"DSSbJTdt0-Kg0KNvcBKsn\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 187.3479488216692,\n \"y\": -62.872994214089545,\n \"strokeColor\": \"#f08c00\",\n \"backgroundColor\": \"#ffffff\",\n \"width\": 101.9562289562289,\n \"height\": 102.97306397306386,\n \"seed\": 1538586915,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"x9RNqZUlFHgvmnRgc473x\"\n },\n {\n \"id\": \"CqnfPKn3XOxytlDa2kd80\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710200414379,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 539,\n \"versionNonce\": 767788227,\n \"isDeleted\": false,\n \"id\": \"x9RNqZUlFHgvmnRgc473x\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 193.60939612449067,\n \"y\": -56.386462227557615,\n \"strokeColor\": \"#f08c00\",\n \"backgroundColor\": \"transparent\",\n \"width\": 89.43333435058594,\n \"height\": 90,\n \"seed\": 791415789,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710200414379,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 36,\n \"fontFamily\": 1,\n \"text\": \"Base\\nFee\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"DSSbJTdt0-Kg0KNvcBKsn\",\n \"originalText\": \"Base \\nFee\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 828,\n \"versionNonce\": 303397939,\n \"isDeleted\": false,\n \"id\": \"zrA8T7sPgkrUAD0ip9_bX\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 357.3199464776727,\n \"y\": -544.6551440367905,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 220.03303564466364,\n \"height\": 392.75521379576475,\n \"seed\": 1586558861,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [\n {\n \"id\": \"Br8JENDpqWwPqPTtdYm4g\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"Q_zGxWSdv4Jf5Wi9wzb4n\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"DXhzqq0zSVnC0CyRzqHKT\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710289604596,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"line\",\n \"version\": 622,\n \"versionNonce\": 479357341,\n \"isDeleted\": false,\n \"id\": \"78CLeBtlugMhRY_tjeFej\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 358.070912469634,\n \"y\": -351.656884102734,\n \"strokeColor\": \"#2f9e44\",\n \"backgroundColor\": \"#ffc9c9\",\n \"width\": 221.53496762858626,\n \"height\": 0,\n \"seed\": 1845788141,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710289604597,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 221.53496762858626,\n 0\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 631,\n \"versionNonce\": 440100093,\n \"isDeleted\": false,\n \"id\": \"4zvjhVRm1_owGOWykoytT\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 381.35085822043453,\n \"y\": -390.7071156847221,\n \"strokeColor\": \"#2f9e44\",\n \"backgroundColor\": \"#ffc9c9\",\n \"width\": 176.06666564941406,\n \"height\": 33.79346963825891,\n \"seed\": 637024333,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710289794196,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 27.03477571060713,\n \"fontFamily\": 1,\n \"text\": \"Gas Target \",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Gas Target \",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 1016,\n \"versionNonce\": 631022429,\n \"isDeleted\": false,\n \"id\": \"2AjExz0KpbZxBLFT6wVu3\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 640.1562194101928,\n \"y\": -81.87299421408966,\n \"strokeColor\": \"#f08c00\",\n \"backgroundColor\": \"transparent\",\n \"width\": 120.95622895622881,\n \"height\": 133.97306397306386,\n \"seed\": 847571053,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"tsbFZGFIE7Ueuzz36Ksoy\"\n },\n {\n \"id\": \"admCWBq6Bszo7Pano9wFV\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"XYc5ZkPR7pwtM_9ZhLFtQ\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710289413244,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 430,\n \"versionNonce\": 508282285,\n \"isDeleted\": false,\n \"id\": \"tsbFZGFIE7Ueuzz36Ksoy\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 646.9176667130142,\n \"y\": -59.88646222755773,\n \"strokeColor\": \"#f08c00\",\n \"backgroundColor\": \"transparent\",\n \"width\": 107.43333435058594,\n \"height\": 90,\n \"seed\": 67588813,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710200414380,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 36,\n \"fontFamily\": 1,\n \"text\": \"Base \\nFee\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"2AjExz0KpbZxBLFT6wVu3\",\n \"originalText\": \"Base \\nFee\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 984,\n \"versionNonce\": 293500835,\n \"isDeleted\": false,\n \"id\": \"jLVC5R80BFTgiIoaq8FJ9\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -287.84378058980747,\n \"y\": -70.8729942140896,\n \"strokeColor\": \"#f08c00\",\n \"backgroundColor\": \"transparent\",\n \"width\": 109.9562289562289,\n \"height\": 107.97306397306386,\n \"seed\": 1676945283,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"IKYnjVQBGTu6OM58rSHz9\"\n },\n {\n \"id\": \"3zmxeEfb4JTT7GAz8IrZW\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710200414380,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 393,\n \"versionNonce\": 629180429,\n \"isDeleted\": false,\n \"id\": \"IKYnjVQBGTu6OM58rSHz9\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -277.582333286986,\n \"y\": -61.88646222755767,\n \"strokeColor\": \"#f08c00\",\n \"backgroundColor\": \"transparent\",\n \"width\": 89.43333435058594,\n \"height\": 90,\n \"seed\": 1386888995,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710200414380,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 36,\n \"fontFamily\": 1,\n \"text\": \"Base\\nFee\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"jLVC5R80BFTgiIoaq8FJ9\",\n \"originalText\": \"Base \\nFee\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"ellipse\",\n \"version\": 342,\n \"versionNonce\": 1454738243,\n \"isDeleted\": false,\n \"id\": \"Kq60_I0edql4zGoSyoChd\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -346.8656661116929,\n \"y\": -522.8864622275578,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 174.14189189189193,\n \"height\": 121,\n \"seed\": 1406243885,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [\n {\n \"id\": \"WioVA79vE4h71iq_2tbfA\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710200414380,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"line\",\n \"version\": 402,\n \"versionNonce\": 1026371069,\n \"isDeleted\": false,\n \"id\": \"xyOwf6mIky1XyoOIpDrMh\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 360.2365924332059,\n \"y\": -487.5414476608592,\n \"strokeColor\": \"#9c36b5\",\n \"backgroundColor\": \"#ffc9c9\",\n \"width\": 213.1680102491235,\n \"height\": 4.934444681692673,\n \"seed\": 1255121123,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710289604597,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 213.1680102491235,\n -4.934444681692673\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 355,\n \"versionNonce\": 1163343187,\n \"isDeleted\": false,\n \"id\": \"IjNVDD7hxfYKEnov6iTcF\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 373.0661486056068,\n \"y\": -534.9121166051088,\n \"strokeColor\": \"#be4bdb\",\n \"backgroundColor\": \"#ffc9c9\",\n \"width\": 185.6999969482422,\n \"height\": 44.41000213523406,\n \"seed\": 915377283,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [\n {\n \"id\": \"XYc5ZkPR7pwtM_9ZhLFtQ\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710289794197,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 35.52800170818725,\n \"fontFamily\": 1,\n \"text\": \"Gas used \",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Gas used \",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"text\",\n \"version\": 516,\n \"versionNonce\": 1189068125,\n \"isDeleted\": false,\n \"id\": \"Tg5y59eICnPk3KAfJqMOc\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 423.3899093851456,\n \"y\": -592.1587273159004,\n \"strokeColor\": \"#e03131\",\n \"backgroundColor\": \"#ffc9c9\",\n \"width\": 127.98332977294922,\n \"height\": 33.79346963825892,\n \"seed\": 1243345091,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710289794197,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 27.034775710607136,\n \"fontFamily\": 1,\n \"text\": \"Gas Limit\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Gas Limit\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 835,\n \"versionNonce\": 9737043,\n \"isDeleted\": false,\n \"id\": \"Lr1X3wqk7zltgMGeWJ1NU\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 763.9834810717807,\n \"y\": -550.8729942140897,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 222.95622895622898,\n \"height\": 397.973063973064,\n \"seed\": 898602925,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [\n {\n \"id\": \"admCWBq6Bszo7Pano9wFV\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"Q_zGxWSdv4Jf5Wi9wzb4n\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"eL1EoX6ew8LCBWoJ99CZ_\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710289550180,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"line\",\n \"version\": 627,\n \"versionNonce\": 1055459117,\n \"isDeleted\": false,\n \"id\": \"sYMK3GqDDUWcEUP2fdJZ3\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 764.7444238327234,\n \"y\": -355.31070465180005,\n \"strokeColor\": \"#2f9e44\",\n \"backgroundColor\": \"#ffc9c9\",\n \"width\": 224.47811447811452,\n \"height\": 0,\n \"seed\": 142219789,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710200414380,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 224.47811447811452,\n 0\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 635,\n \"versionNonce\": 1164971555,\n \"isDeleted\": false,\n \"id\": \"TnOwiLJFKby8TK7XLV80n\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 788.333649421949,\n \"y\": -394.8797282208236,\n \"strokeColor\": \"#2f9e44\",\n \"backgroundColor\": \"#ffc9c9\",\n \"width\": 178.48333740234375,\n \"height\": 34.24242424242424,\n \"seed\": 1940213869,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710200414380,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 27.393939393939394,\n \"fontFamily\": 1,\n \"text\": \"Gas Target \",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Gas Target \",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"text\",\n \"version\": 522,\n \"versionNonce\": 595043549,\n \"isDeleted\": false,\n \"id\": \"BCA_hwW8OFs8kLpVhCwh7\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 825.2676651871352,\n \"y\": -598.0076743487699,\n \"strokeColor\": \"#e03131\",\n \"backgroundColor\": \"#ffc9c9\",\n \"width\": 129.73333740234375,\n \"height\": 34.24242424242424,\n \"seed\": 1719039853,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710289566282,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 27.393939393939394,\n \"fontFamily\": 1,\n \"text\": \"Gas Limit\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Gas Limit\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 357,\n \"versionNonce\": 1310265325,\n \"isDeleted\": false,\n \"id\": \"22cb57NPQtd7X1SzeocVh\",\n \"fillStyle\": \"cross-hatch\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 186.13433388830697,\n \"y\": -61.88646222755767,\n \"strokeColor\": \"#e03131\",\n \"backgroundColor\": \"#fa5252\",\n \"width\": 99.00000000000001,\n \"height\": 23.000000000000004,\n \"seed\": 1594278253,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [\n {\n \"id\": \"Br8JENDpqWwPqPTtdYm4g\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710200467856,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 365,\n \"versionNonce\": 1913184237,\n \"isDeleted\": false,\n \"id\": \"twQd3AZYJVRhwL0VVUzhK\",\n \"fillStyle\": \"cross-hatch\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 126.13433388830697,\n \"y\": 80.11353777244233,\n \"strokeColor\": \"#f08c00\",\n \"backgroundColor\": \"#1e1e1e\",\n \"width\": 240.6666717529297,\n \"height\": 30,\n \"seed\": 1154577805,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [\n {\n \"id\": \"CqnfPKn3XOxytlDa2kd80\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710200414380,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 24,\n \"fontFamily\": 1,\n \"text\": \"max 12.5% decrease\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"max 12.5% decrease\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"text\",\n \"version\": 257,\n \"versionNonce\": 1712302973,\n \"isDeleted\": false,\n \"id\": \"0SPbnbbLjDSMoKhvpBeVr\",\n \"fillStyle\": \"cross-hatch\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 563.3565527196873,\n \"y\": 75.11353777244233,\n \"strokeColor\": \"#f08c00\",\n \"backgroundColor\": \"#1e1e1e\",\n \"width\": 230.3333282470703,\n \"height\": 30,\n \"seed\": 507348685,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710289439078,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 24,\n \"fontFamily\": 1,\n \"text\": \"max 12.5% increase\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"max 12.5% increase\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"arrow\",\n \"version\": 131,\n \"versionNonce\": 790649421,\n \"isDeleted\": false,\n \"id\": \"3zmxeEfb4JTT7GAz8IrZW\",\n \"fillStyle\": \"cross-hatch\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -247.8656661116931,\n \"y\": -84.88646222755767,\n \"strokeColor\": \"#f08c00\",\n \"backgroundColor\": \"#1e1e1e\",\n \"width\": 80,\n \"height\": 121,\n \"seed\": 656038733,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710200414380,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"jLVC5R80BFTgiIoaq8FJ9\",\n \"focus\": -0.6041179088833702,\n \"gap\": 14.01346801346807\n },\n \"endBinding\": {\n \"elementId\": \"za7W4B5dR7ChlMslpX4wu\",\n \"focus\": -0.010544858865763923,\n \"gap\": 8.666574331952347\n },\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 35,\n -68\n ],\n [\n 80,\n -121\n ]\n ]\n },\n {\n \"type\": \"arrow\",\n \"version\": 182,\n \"versionNonce\": 419297235,\n \"isDeleted\": false,\n \"id\": \"Br8JENDpqWwPqPTtdYm4g\",\n \"fillStyle\": \"cross-hatch\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 237.72529115707857,\n \"y\": -62.88646222755767,\n \"strokeColor\": \"#f08c00\",\n \"backgroundColor\": \"#1e1e1e\",\n \"width\": 118.59465532059414,\n \"height\": 156.76218095094177,\n \"seed\": 602892035,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710289604831,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"22cb57NPQtd7X1SzeocVh\",\n \"gap\": 1,\n \"focus\": -0.10714909980772591\n },\n \"endBinding\": {\n \"elementId\": \"zrA8T7sPgkrUAD0ip9_bX\",\n \"gap\": 1,\n \"focus\": -0.01135657692699058\n },\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 58.409042731228396,\n -89\n ],\n [\n 118.59465532059414,\n -156.76218095094177\n ]\n ]\n },\n {\n \"type\": \"arrow\",\n \"version\": 208,\n \"versionNonce\": 605653165,\n \"isDeleted\": false,\n \"id\": \"admCWBq6Bszo7Pano9wFV\",\n \"fillStyle\": \"cross-hatch\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 693.7125533055627,\n \"y\": -83.88646222755767,\n \"strokeColor\": \"#f08c00\",\n \"backgroundColor\": \"#1e1e1e\",\n \"width\": 62.42178058274442,\n \"height\": 201.00000000000006,\n \"seed\": 118902797,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710200414380,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"2AjExz0KpbZxBLFT6wVu3\",\n \"gap\": 2.013468013468014,\n \"focus\": -0.29649533807439415\n },\n \"endBinding\": {\n \"elementId\": \"Lr1X3wqk7zltgMGeWJ1NU\",\n \"focus\": 0.47324933484534304,\n \"gap\": 7.84914718347369\n },\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 24.421780582744418,\n -109\n ],\n [\n 62.42178058274442,\n -201.00000000000006\n ]\n ]\n },\n {\n \"type\": \"arrow\",\n \"version\": 192,\n \"versionNonce\": 1789027491,\n \"isDeleted\": false,\n \"id\": \"EwJaRDbgj9lT-spTp7aMe\",\n \"fillStyle\": \"cross-hatch\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 128.13433388830697,\n \"y\": -374.8864622275577,\n \"strokeColor\": \"#f08c00\",\n \"backgroundColor\": \"#1e1e1e\",\n \"width\": 145,\n \"height\": 0,\n \"seed\": 1975845485,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710200414380,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 145,\n 0\n ]\n ]\n },\n {\n \"type\": \"arrow\",\n \"version\": 248,\n \"versionNonce\": 1768578835,\n \"isDeleted\": false,\n \"id\": \"Q_zGxWSdv4Jf5Wi9wzb4n\",\n \"fillStyle\": \"cross-hatch\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 599.0311896568081,\n \"y\": -372.84927833881386,\n \"strokeColor\": \"#f08c00\",\n \"backgroundColor\": \"#1e1e1e\",\n \"width\": 147.92319331156534,\n \"height\": 1.0571240221023572,\n \"seed\": 663635053,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710289604832,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"zrA8T7sPgkrUAD0ip9_bX\",\n \"gap\": 21.678207534471767,\n \"focus\": -0.11984146949289895\n },\n \"endBinding\": {\n \"elementId\": \"Lr1X3wqk7zltgMGeWJ1NU\",\n \"gap\": 17.029098103407307,\n \"focus\": 0.11481600374897827\n },\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 147.92319331156534,\n -1.0571240221023572\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 94,\n \"versionNonce\": 517199939,\n \"isDeleted\": false,\n \"id\": \"9ZUNz4Hm1eEOSWnBEqyAO\",\n \"fillStyle\": \"cross-hatch\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 117.13433388830697,\n \"y\": -452.88646222755773,\n \"strokeColor\": \"#f08c00\",\n \"backgroundColor\": \"#1e1e1e\",\n \"width\": 192.63333129882812,\n \"height\": 45,\n \"seed\": 1676709027,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710200414380,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 36,\n \"fontFamily\": 1,\n \"text\": \"Next Block\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Next Block\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"arrow\",\n \"version\": 636,\n \"versionNonce\": 481525331,\n \"isDeleted\": false,\n \"id\": \"CqnfPKn3XOxytlDa2kd80\",\n \"fillStyle\": \"cross-hatch\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dotted\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 157.30496804813356,\n \"y\": 75.11353777244238,\n \"strokeColor\": \"#f08c00\",\n \"backgroundColor\": \"#1e1e1e\",\n \"width\": 86.02064026334209,\n \"height\": 258.81478148318234,\n \"seed\": 775442243,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710289750877,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"twQd3AZYJVRhwL0VVUzhK\",\n \"focus\": -0.6806208910137249,\n \"gap\": 4.999999999999929\n },\n \"endBinding\": {\n \"elementId\": \"2vmEJeyKU7ZmHPTqunJrb\",\n \"focus\": -0.9301151669505678,\n \"gap\": 11.000000000000071\n },\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -33.17063415982659,\n -138.00000000000006\n ],\n [\n -86.02064026334209,\n -258.81478148318234\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 321,\n \"versionNonce\": 1748618931,\n \"isDeleted\": false,\n \"id\": \"6a5oLykOqy_YVB0WAN-Sx\",\n \"fillStyle\": \"cross-hatch\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dotted\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 1.3621548148781173,\n \"x\": 76.2443745925782,\n \"y\": -71.57485303526869,\n \"strokeColor\": \"#f08c00\",\n \"backgroundColor\": \"#1e1e1e\",\n \"width\": 147.64999389648438,\n \"height\": 45,\n \"seed\": 1800430765,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710289361584,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 36,\n \"fontFamily\": 1,\n \"text\": \"Because\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Because\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"arrow\",\n \"version\": 97,\n \"versionNonce\": 1392397261,\n \"isDeleted\": false,\n \"id\": \"TGsI_OUzRPf0sbr7NLacH\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 818.1343338883071,\n \"y\": 110.11353777244233,\n \"strokeColor\": \"#2f9e44\",\n \"backgroundColor\": \"#1e1e1e\",\n \"width\": 4,\n \"height\": 42,\n \"seed\": 752740195,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710200414380,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -4,\n -42\n ]\n ]\n },\n {\n \"type\": \"arrow\",\n \"version\": 199,\n \"versionNonce\": 464970627,\n \"isDeleted\": false,\n \"id\": \"uO8HvmNc6XyQSdCBocjSy\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 384.46044820049383,\n \"y\": 84.25918667999574,\n \"strokeColor\": \"#e03131\",\n \"backgroundColor\": \"#1e1e1e\",\n \"width\": 2,\n \"height\": 57,\n \"seed\": 604048323,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710200414380,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 2,\n 57\n ]\n ]\n },\n {\n \"type\": \"line\",\n \"version\": 202,\n \"versionNonce\": 1245530669,\n \"isDeleted\": false,\n \"id\": \"muRfKOlWAcVAu9AMZ09qV\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -200.8656661116931,\n \"y\": 143.11353777244227,\n \"strokeColor\": \"#2f9e44\",\n \"backgroundColor\": \"#1e1e1e\",\n \"width\": 961.0000000000002,\n \"height\": 90,\n \"seed\": 2046003811,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710200414380,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 209.00000000000006,\n 90\n ],\n [\n 961.0000000000002,\n 39\n ]\n ]\n },\n {\n \"type\": \"arrow\",\n \"version\": 851,\n \"versionNonce\": 2058713891,\n \"isDeleted\": false,\n \"id\": \"LMMgnY7E7MFx_ajOMBLx3\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -43.51122514399104,\n \"y\": 241.12961926837454,\n \"strokeColor\": \"#2f9e44\",\n \"backgroundColor\": \"#1e1e1e\",\n \"width\": 117.00000000000006,\n \"height\": 156.9839185040678,\n \"seed\": 1515879555,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710200414380,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"Ne7CJ26YuFBnPRV1U-2sL\",\n \"focus\": -1.1929232384395196,\n \"gap\": 15.358735764761548\n },\n \"endBinding\": {\n \"elementId\": \"lvQu-72vu_YeX08T7MtcF\",\n \"focus\": 0.8711356558040979,\n \"gap\": 18\n },\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -38.35444096770204,\n 156.9839185040678\n ],\n [\n 78.64555903229802,\n 88.28935824916095\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 202,\n \"versionNonce\": 1372421261,\n \"isDeleted\": false,\n \"id\": \"lvQu-72vu_YeX08T7MtcF\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 53.13433388830697,\n \"y\": 279.1135377724423,\n \"strokeColor\": \"#f08c00\",\n \"backgroundColor\": \"#1e1e1e\",\n \"width\": 897.1166381835938,\n \"height\": 90,\n \"seed\": 910552525,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [\n {\n \"id\": \"LMMgnY7E7MFx_ajOMBLx3\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710200414380,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 36,\n \"fontFamily\": 1,\n \"text\": \"Base Fee is adjusted so that blocks on average \\nconsume as much as the gas target\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Base Fee is adjusted so that blocks on average \\nconsume as much as the gas target\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 806,\n \"versionNonce\": 423632579,\n \"isDeleted\": false,\n \"id\": \"LkyUuEQUdjMfl0k49SrVH\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -302.39098674491504,\n \"y\": 452.89215947775733,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 155.46255776748873,\n \"height\": 220.20791028121695,\n \"seed\": 982393027,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710200414380,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"line\",\n \"version\": 1036,\n \"versionNonce\": 828924653,\n \"isDeleted\": false,\n \"id\": \"FLT-PNCGM6Q8hBvs8XQm1\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 50,\n \"angle\": 5.098449016051533,\n \"x\": -280.3858648573413,\n \"y\": 279.2254842817508,\n \"strokeColor\": \"#2f9e44\",\n \"backgroundColor\": \"#ffc9c9\",\n \"width\": 108.86722694146003,\n \"height\": 0,\n \"seed\": 725790051,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710200414380,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 108.86722694146003,\n 0\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 1045,\n \"versionNonce\": 1106595427,\n \"isDeleted\": false,\n \"id\": \"Jxr1dHIOy2Q6gzV1mNG0_\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 50,\n \"angle\": 5.098449016051533,\n \"x\": -276.8818846217844,\n \"y\": 267.14283431232695,\n \"strokeColor\": \"#2f9e44\",\n \"backgroundColor\": \"#ffc9c9\",\n \"width\": 86.51667022705078,\n \"height\": 16.60686512666339,\n \"seed\": 502073603,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710200414380,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 13.285492101330712,\n \"fontFamily\": 1,\n \"text\": \"Gas Target \",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Gas Target \",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"line\",\n \"version\": 945,\n \"versionNonce\": 2107080013,\n \"isDeleted\": false,\n \"id\": \"TsqCokmKF-LWIxw9kX4ht\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 50,\n \"angle\": 5.098449016051533,\n \"x\": -299.1805089085606,\n \"y\": 270.92311630088994,\n \"strokeColor\": \"#9c36b5\",\n \"backgroundColor\": \"#ffc9c9\",\n \"width\": 104.75551736535988,\n \"height\": 2.424896235309256,\n \"seed\": 1846210723,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710200414380,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 104.75551736535988,\n -2.424896235309256\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 910,\n \"versionNonce\": 1738770947,\n \"isDeleted\": false,\n \"id\": \"oJpnupeDAOIgWgKHzaoWL\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 50,\n \"angle\": 5.098449016051533,\n \"x\": -308.3501359254386,\n \"y\": 258.00681017238804,\n \"strokeColor\": \"#be4bdb\",\n \"backgroundColor\": \"#ffc9c9\",\n \"width\": 91.26667022705078,\n \"height\": 21.824066117783303,\n \"seed\": 1028318275,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710200414380,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 17.459252894226644,\n \"fontFamily\": 1,\n \"text\": \"Gas used \",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Gas used \",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 1569,\n \"versionNonce\": 2108967853,\n \"isDeleted\": false,\n \"id\": \"foro_H5GGqqTQjLs61Oh1\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 50,\n \"angle\": 5.045895957944246,\n \"x\": -262.9842867173918,\n \"y\": 181.99729813854032,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 96.75584513011812,\n \"height\": 172.70753243362378,\n \"seed\": 350720589,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710200414380,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"line\",\n \"version\": 1416,\n \"versionNonce\": 524898723,\n \"isDeleted\": false,\n \"id\": \"_gi_qkvFeHaS_OBBtbAXq\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 50,\n \"angle\": 5.098449016051533,\n \"x\": -264.39837822195204,\n \"y\": 268.7064840027075,\n \"strokeColor\": \"#2f9e44\",\n \"backgroundColor\": \"#ffc9c9\",\n \"width\": 97.41629458493121,\n \"height\": 0,\n \"seed\": 1010417837,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710200414380,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 97.41629458493121,\n 0\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 1425,\n \"versionNonce\": 1374178829,\n \"isDeleted\": false,\n \"id\": \"hk2vtCue36QAdNVFFtBWQ\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 50,\n \"angle\": 5.098449016051533,\n \"x\": -265.21275097479514,\n \"y\": 257.77407531484334,\n \"strokeColor\": \"#2f9e44\",\n \"backgroundColor\": \"#ffc9c9\",\n \"width\": 77.43333435058594,\n \"height\": 14.860112733294589,\n \"seed\": 1777804045,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710200414380,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 11.88809018663567,\n \"fontFamily\": 1,\n \"text\": \"Gas Target \",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Gas Target \",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"line\",\n \"version\": 1140,\n \"versionNonce\": 1511335235,\n \"isDeleted\": false,\n \"id\": \"TUbvcSm0Soeo7YDdQMqno\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 50,\n \"angle\": 5.098449016051533,\n \"x\": -233.11027616065167,\n \"y\": 282.26725283780735,\n \"strokeColor\": \"#9c36b5\",\n \"backgroundColor\": \"#ffc9c9\",\n \"width\": 93.7370650999326,\n \"height\": 2.1698394699058468,\n \"seed\": 312031597,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710200414380,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 93.7370650999326,\n -2.1698394699058468\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 1103,\n \"versionNonce\": 1496122477,\n \"isDeleted\": false,\n \"id\": \"Ou15ZAaAaUahgXpjjatdf\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 50,\n \"angle\": 5.098449016051533,\n \"x\": -241.33402756364532,\n \"y\": 269.0812880899407,\n \"strokeColor\": \"#be4bdb\",\n \"backgroundColor\": \"#ffc9c9\",\n \"width\": 81.5999984741211,\n \"height\": 19.528555229152623,\n \"seed\": 1600750541,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710200414380,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 15.6228441833221,\n \"fontFamily\": 1,\n \"text\": \"Gas used \",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Gas used \",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 1369,\n \"versionNonce\": 1600488675,\n \"isDeleted\": false,\n \"id\": \"Lutb20-vzUexRXQlUGfBd\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 50,\n \"angle\": 5.092933394215817,\n \"x\": -280.8350817787225,\n \"y\": 195.50676045282864,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 108.12914404694165,\n \"height\": 193.00867691655452,\n \"seed\": 2112193421,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710200414380,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"line\",\n \"version\": 1184,\n \"versionNonce\": 1464594125,\n \"isDeleted\": false,\n \"id\": \"mbslkXsq1ijY4c0zuWj9a\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 50,\n \"angle\": 5.098449016051533,\n \"x\": -291.0923183744709,\n \"y\": 293.2699219345019,\n \"strokeColor\": \"#2f9e44\",\n \"backgroundColor\": \"#ffc9c9\",\n \"width\": 108.86722694146003,\n \"height\": 0,\n \"seed\": 1256688109,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710200414380,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 108.86722694146003,\n 0\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 1193,\n \"versionNonce\": 113832067,\n \"isDeleted\": false,\n \"id\": \"BcEmvCVBbwHMwqp34qQ0K\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 50,\n \"angle\": 5.098449016051533,\n \"x\": -289.3555655653748,\n \"y\": 279.98394072838727,\n \"strokeColor\": \"#2f9e44\",\n \"backgroundColor\": \"#ffc9c9\",\n \"width\": 86.51667022705078,\n \"height\": 16.60686512666339,\n \"seed\": 177849421,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710200414380,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 13.285492101330712,\n \"fontFamily\": 1,\n \"text\": \"Gas Target \",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Gas Target \",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"line\",\n \"version\": 1093,\n \"versionNonce\": 1524534573,\n \"isDeleted\": false,\n \"id\": \"VRl89jxll65tGlTVRCzfu\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 50,\n \"angle\": 5.098449016051533,\n \"x\": -311.1717116306627,\n \"y\": 285.4032294261033,\n \"strokeColor\": \"#9c36b5\",\n \"backgroundColor\": \"#ffc9c9\",\n \"width\": 104.75551736535988,\n \"height\": 2.424896235309256,\n \"seed\": 1624617645,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710200414380,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 104.75551736535988,\n -2.424896235309256\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 1058,\n \"versionNonce\": 838723619,\n \"isDeleted\": false,\n \"id\": \"bx4Glzs3zRWOAD0xKwTGr\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 50,\n \"angle\": 5.098449016051533,\n \"x\": -320.823816869029,\n \"y\": 270.8479165884483,\n \"strokeColor\": \"#be4bdb\",\n \"backgroundColor\": \"#ffc9c9\",\n \"width\": 91.26667022705078,\n \"height\": 21.824066117783303,\n \"seed\": 977589517,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710200414380,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 17.459252894226644,\n \"fontFamily\": 1,\n \"text\": \"Gas used \",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Gas used \",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 1734,\n \"versionNonce\": 1666080653,\n \"isDeleted\": false,\n \"id\": \"VRHhBfl7rXs68HbQfaeVR\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 50,\n \"angle\": 5.098449016051533,\n \"x\": -269.28752544837556,\n \"y\": 194.75840187727368,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 96.75584513011812,\n \"height\": 172.70753243362378,\n \"seed\": 845196141,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710200414380,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"line\",\n \"version\": 1564,\n \"versionNonce\": 116583363,\n \"isDeleted\": false,\n \"id\": \"zl7AVrqugIE58MJxGJqMr\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 50,\n \"angle\": 5.098449016051533,\n \"x\": -279.77335238680047,\n \"y\": 282.7234286205239,\n \"strokeColor\": \"#2f9e44\",\n \"backgroundColor\": \"#ffc9c9\",\n \"width\": 97.41629458493121,\n \"height\": 0,\n \"seed\": 963818957,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710200414380,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 97.41629458493121,\n 0\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 1575,\n \"versionNonce\": 1188357613,\n \"isDeleted\": false,\n \"id\": \"jowkz3GMwz20tFutJXlA6\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 50,\n \"angle\": 5.098449016051533,\n \"x\": -278.81605601325043,\n \"y\": 273.39438114877584,\n \"strokeColor\": \"#2f9e44\",\n \"backgroundColor\": \"#ffc9c9\",\n \"width\": 77.43333435058594,\n \"height\": 14.860112733294589,\n \"seed\": 2056549421,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710200414380,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 11.88809018663567,\n \"fontFamily\": 1,\n \"text\": \"Gas Target \",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Gas Target \",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"line\",\n \"version\": 1326,\n \"versionNonce\": 1774615395,\n \"isDeleted\": false,\n \"id\": \"bUYwRwiSkvOb4y6jkiqMi\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 50,\n \"angle\": 5.098449016051533,\n \"x\": -241.23700443661502,\n \"y\": 295.26025620926674,\n \"strokeColor\": \"#9c36b5\",\n \"backgroundColor\": \"#ffc9c9\",\n \"width\": 93.7370650999326,\n \"height\": 2.1698394699058468,\n \"seed\": 28272269,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710200414380,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 93.7370650999326,\n -2.1698394699058468\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 1304,\n \"versionNonce\": 1484496973,\n \"isDeleted\": false,\n \"id\": \"Bdx6BIZQFnw6hma2lpHjf\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 50,\n \"angle\": 5.098449016051533,\n \"x\": -253.80770850723556,\n \"y\": 281.9223945060008,\n \"strokeColor\": \"#be4bdb\",\n \"backgroundColor\": \"#ffc9c9\",\n \"width\": 81.5999984741211,\n \"height\": 19.528555229152623,\n \"seed\": 561843437,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710200414380,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 15.6228441833221,\n \"fontFamily\": 1,\n \"text\": \"Gas used \",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Gas used \",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"text\",\n \"version\": 473,\n \"versionNonce\": 919017219,\n \"isDeleted\": false,\n \"id\": \"Ne7CJ26YuFBnPRV1U-2sL\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 5.00367327193491,\n \"x\": -274.4636122797655,\n \"y\": 218.62194978821512,\n \"strokeColor\": \"#1971c2\",\n \"backgroundColor\": \"#1e1e1e\",\n \"width\": 396.29998779296875,\n \"height\": 35,\n \"seed\": 1411041251,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [\n {\n \"id\": \"z6DQjX06JjK1kZQ6S0xha\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"LMMgnY7E7MFx_ajOMBLx3\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710200414381,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 28,\n \"fontFamily\": 1,\n \"text\": \"Net Effect On Many Blocks\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Net Effect On Many Blocks\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"arrow\",\n \"version\": 287,\n \"versionNonce\": 1310461613,\n \"isDeleted\": false,\n \"id\": \"z6DQjX06JjK1kZQ6S0xha\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -47.41663647668988,\n \"y\": 244.90735891940915,\n \"strokeColor\": \"#2f9e44\",\n \"backgroundColor\": \"#1e1e1e\",\n \"width\": 67.25294732757135,\n \"height\": 265.18476268938787,\n \"seed\": 2059967299,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710200414381,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"Ne7CJ26YuFBnPRV1U-2sL\",\n \"focus\": -1.1608541046848824,\n \"gap\": 12.702737903598234\n },\n \"endBinding\": {\n \"elementId\": \"XWBs9KSzsIdsFrWhfIV15\",\n \"focus\": -1.2166248431784543,\n \"gap\": 9.260316423550705\n },\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -67.25294732757135,\n 265.18476268938787\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 63,\n \"versionNonce\": 1014185635,\n \"isDeleted\": false,\n \"id\": \"XWBs9KSzsIdsFrWhfIV15\",\n \"fillStyle\": \"hachure\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -107.86566611169303,\n \"y\": 516.373854195993,\n \"strokeColor\": \"#2f9e44\",\n \"backgroundColor\": \"#1e1e1e\",\n \"width\": 51.21666717529297,\n \"height\": 103.73968357644944,\n \"seed\": 387980077,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [\n {\n \"id\": \"z6DQjX06JjK1kZQ6S0xha\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710200414381,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 82.99174686115956,\n \"fontFamily\": 1,\n \"text\": \"=\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"=\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 821,\n \"versionNonce\": 1717547277,\n \"isDeleted\": false,\n \"id\": \"XlpY703MFhqw8_T8hoIge\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -22.304277111718704,\n \"y\": 471.00958263183384,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 155.46255776748873,\n \"height\": 220.20791028121695,\n \"seed\": 1163548579,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710200414381,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"line\",\n \"version\": 492,\n \"versionNonce\": 1970893379,\n \"isDeleted\": false,\n \"id\": \"CEO5gQyjYbl1y-Ea-1ZyS\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -24.753210361659,\n \"y\": 570.633737397174,\n \"strokeColor\": \"#2f9e44\",\n \"backgroundColor\": \"#ffc9c9\",\n \"width\": 162.56469126760808,\n \"height\": 0,\n \"seed\": 1679125315,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710200414381,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 162.56469126760808,\n 0\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 359,\n \"versionNonce\": 1321207661,\n \"isDeleted\": false,\n \"id\": \"EQ8-9j9_QEymOdbi6T-1l\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -1.1073348128649059,\n \"y\": 533.9923256512302,\n \"strokeColor\": \"#2f9e44\",\n \"backgroundColor\": \"#ffc9c9\",\n \"width\": 136.48333740234375,\n \"height\": 26.18463106624771,\n \"seed\": 884749165,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710200414381,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 20.947704852998168,\n \"fontFamily\": 1,\n \"text\": \"Gas Target \",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Gas Target \",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 111,\n \"versionNonce\": 91734931,\n \"isDeleted\": false,\n \"id\": \"I7MPqA_RggotRjG7lQMla\",\n \"fillStyle\": \"cross-hatch\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 359.1105453394596,\n \"y\": -544.6684354702766,\n \"strokeColor\": \"#e03131\",\n \"backgroundColor\": \"#fa5252\",\n \"width\": 224.02378854884748,\n \"height\": 14.803334045078023,\n \"seed\": 1536649901,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"DXhzqq0zSVnC0CyRzqHKT\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710289604597,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"rectangle\",\n \"version\": 202,\n \"versionNonce\": 2082313725,\n \"isDeleted\": false,\n \"id\": \"-TEyNE1hJWMUk6pvxSb7S\",\n \"fillStyle\": \"cross-hatch\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 766.634333888307,\n \"y\": -553.3864622275578,\n \"strokeColor\": \"#2f9e44\",\n \"backgroundColor\": \"#b2f2bb\",\n \"width\": 227.0000000000001,\n \"height\": 15.000000000000002,\n \"seed\": 409430051,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [],\n \"updated\": 1710289579443,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"arrow\",\n \"version\": 548,\n \"versionNonce\": 1349125309,\n \"isDeleted\": false,\n \"id\": \"DXhzqq0zSVnC0CyRzqHKT\",\n \"fillStyle\": \"cross-hatch\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 92.13433388830697,\n \"y\": -565.5613665281155,\n \"strokeColor\": \"#e03131\",\n \"backgroundColor\": \"#fa5252\",\n \"width\": 228.9082997957634,\n \"height\": 35.734055927205986,\n \"seed\": 1235457517,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710289501665,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"h9wLd7arqM4etSy-pR3-0\",\n \"focus\": 1.3253732106778848,\n \"gap\": 7.651945722733217\n },\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 147,\n -19.325095699442272\n ],\n [\n 228.9082997957634,\n 16.408960227763714\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 198,\n \"versionNonce\": 320742333,\n \"isDeleted\": false,\n \"id\": \"h9wLd7arqM4etSy-pR3-0\",\n \"fillStyle\": \"cross-hatch\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 6.118868396451672,\n \"x\": 78.13433388830697,\n \"y\": -631.8864622275578,\n \"strokeColor\": \"#e03131\",\n \"backgroundColor\": \"#fa5252\",\n \"width\": 309.3999938964844,\n \"height\": 35,\n \"seed\": 1175955587,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [\n {\n \"id\": \"DXhzqq0zSVnC0CyRzqHKT\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710289479181,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 28,\n \"fontFamily\": 1,\n \"text\": \"Max Change GasLimit \",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Max Change GasLimit \",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"line\",\n \"version\": 120,\n \"versionNonce\": 463248275,\n \"isDeleted\": false,\n \"id\": \"Z2ktoyQ0tjmNznHrFhPgu\",\n \"fillStyle\": \"cross-hatch\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 312.13433388830697,\n \"y\": -598.8864622275578,\n \"strokeColor\": \"#e03131\",\n \"backgroundColor\": \"#fa5252\",\n \"width\": 106,\n \"height\": 53,\n \"seed\": 1238678669,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710289486308,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 106,\n -53\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 113,\n \"versionNonce\": 1296430643,\n \"isDeleted\": false,\n \"id\": \"fPioeT-d4xDXlf7AtCvrr\",\n \"fillStyle\": \"cross-hatch\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 5.817221582438705,\n \"x\": 345.13433388830697,\n \"y\": -613.8864622275578,\n \"strokeColor\": \"#e03131\",\n \"backgroundColor\": \"#fa5252\",\n \"width\": 64.69999694824219,\n \"height\": 35,\n \"seed\": 1693820387,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710289492374,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 28,\n \"fontFamily\": 1,\n \"text\": \"1024\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"1024\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"arrow\",\n \"version\": 320,\n \"versionNonce\": 726186179,\n \"isDeleted\": false,\n \"id\": \"CVp6t9bsdUSeoLvHJ8Ud7\",\n \"fillStyle\": \"cross-hatch\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 539.1343338883071,\n \"y\": 741.1135377724423,\n \"strokeColor\": \"#fd7e14\",\n \"backgroundColor\": \"#fa5252\",\n \"width\": 1.0000000000001137,\n \"height\": 317,\n \"seed\": 972223395,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710200414381,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"GTpKVn7DqFQiOrjIMnko8\",\n \"focus\": -1.0566019464484573,\n \"gap\": 8\n },\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 1.0000000000001137,\n -317\n ]\n ]\n },\n {\n \"type\": \"arrow\",\n \"version\": 415,\n \"versionNonce\": 357460205,\n \"isDeleted\": false,\n \"id\": \"qHHUES1_YFWCEtgrq71Wp\",\n \"fillStyle\": \"cross-hatch\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 531.543971837215,\n \"y\": 742.0280968607173,\n \"strokeColor\": \"#9c36b5\",\n \"backgroundColor\": \"#fa5252\",\n \"width\": 426,\n \"height\": 2.0000000000001137,\n \"seed\": 1083528515,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710200414381,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"GTpKVn7DqFQiOrjIMnko8\",\n \"focus\": 1.0723292568691638,\n \"gap\": 15.590362051092029\n },\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 426,\n 2.0000000000001137\n ]\n ]\n },\n {\n \"type\": \"line\",\n \"version\": 503,\n \"versionNonce\": 2077927523,\n \"isDeleted\": false,\n \"id\": \"rA8ZYO3qVllcbmTM7DMbB\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -299.55338927567817,\n \"y\": 567.6798631458756,\n \"strokeColor\": \"#9c36b5\",\n \"backgroundColor\": \"#ffc9c9\",\n \"width\": 155.48971450330967,\n \"height\": 3.5992989468358716,\n \"seed\": 1523030349,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710200414381,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 155.48971450330967,\n -3.5992989468358716\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 466,\n \"versionNonce\": 1120715597,\n \"isDeleted\": false,\n \"id\": \"mGmE7wayU5xpkPYhhO9Gd\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -295.9540903288423,\n \"y\": 527.3677149413139,\n \"strokeColor\": \"#be4bdb\",\n \"backgroundColor\": \"#ffc9c9\",\n \"width\": 135.4499969482422,\n \"height\": 32.39369052152284,\n \"seed\": 1988159405,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710200414381,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 25.914952417218274,\n \"fontFamily\": 1,\n \"text\": \"Gas used \",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Gas used \",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"text\",\n \"version\": 57,\n \"versionNonce\": 802006019,\n \"isDeleted\": false,\n \"id\": \"64tUedKZbVIcYUYN22sXW\",\n \"fillStyle\": \"cross-hatch\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 605.1343338883071,\n \"y\": 776.1135377724423,\n \"strokeColor\": \"#9c36b5\",\n \"backgroundColor\": \"#fa5252\",\n \"width\": 385.1333312988281,\n \"height\": 45,\n \"seed\": 1263532237,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710200414381,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 36,\n \"fontFamily\": 1,\n \"text\": \"Gas Used (units gas)\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Gas Used (units gas)\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"text\",\n \"version\": 708,\n \"versionNonce\": 490119437,\n \"isDeleted\": false,\n \"id\": \"KkUIn7focYU6vcjSrMie1\",\n \"fillStyle\": \"cross-hatch\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 4.713198507808203,\n \"x\": 268.05110044624064,\n \"y\": 528.3872285899151,\n \"strokeColor\": \"#f08c00\",\n \"backgroundColor\": \"#fa5252\",\n \"width\": 371.9166564941406,\n \"height\": 77.54398491100737,\n \"seed\": 1541454851,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710200845361,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 31.01759396440295,\n \"fontFamily\": 1,\n \"text\": \"Base Fee + Priority Fee\\n (units gwei)\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Base Fee + Priority Fee\\n (units gwei)\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 348,\n \"versionNonce\": 1327508387,\n \"isDeleted\": false,\n \"id\": \"GTpKVn7DqFQiOrjIMnko8\",\n \"fillStyle\": \"cross-hatch\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 547.1343338883071,\n \"y\": 543.1135377724423,\n \"strokeColor\": \"#f08c00\",\n \"backgroundColor\": \"#ffec99\",\n \"width\": 260,\n \"height\": 192,\n \"seed\": 1421460749,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [\n {\n \"id\": \"CVp6t9bsdUSeoLvHJ8Ud7\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"qHHUES1_YFWCEtgrq71Wp\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710200414381,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"line\",\n \"version\": 67,\n \"versionNonce\": 1392776205,\n \"isDeleted\": false,\n \"id\": \"JlGmPqm83CI-gyuzLEX2a\",\n \"fillStyle\": \"cross-hatch\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 523.1343338883071,\n \"y\": 548.1135377724423,\n \"strokeColor\": \"#1971c2\",\n \"backgroundColor\": \"#b2f2bb\",\n \"width\": 49,\n \"height\": 6,\n \"seed\": 2062904227,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710200414381,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 49,\n -6\n ]\n ]\n },\n {\n \"type\": \"line\",\n \"version\": 35,\n \"versionNonce\": 1577107267,\n \"isDeleted\": false,\n \"id\": \"-qmoH7jzwRa72fWoRiJmx\",\n \"fillStyle\": \"cross-hatch\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 808.1343338883071,\n \"y\": 760.1135377724423,\n \"strokeColor\": \"#1971c2\",\n \"backgroundColor\": \"#b2f2bb\",\n \"width\": 1,\n \"height\": 34,\n \"seed\": 219269475,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710200414381,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -1,\n -34\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 180,\n \"versionNonce\": 249563757,\n \"isDeleted\": false,\n \"id\": \"SiZ4k0ZelsShEuCcgTIaa\",\n \"fillStyle\": \"cross-hatch\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 564.1343338883071,\n \"y\": 613.1135377724423,\n \"strokeColor\": \"#e8590c\",\n \"backgroundColor\": \"#b2f2bb\",\n \"width\": 216.4166717529297,\n \"height\": 90,\n \"seed\": 68434051,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710200414381,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 36,\n \"fontFamily\": 1,\n \"text\": \"TOTAL FEE\\n\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"TOTAL FEE\\n\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"arrow\",\n \"version\": 197,\n \"versionNonce\": 1456332515,\n \"isDeleted\": false,\n \"id\": \"thgsoVvBTFGGTo776yQIY\",\n \"fillStyle\": \"cross-hatch\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 754.1343338883071,\n \"y\": 582.1135377724423,\n \"strokeColor\": \"#f08c00\",\n \"backgroundColor\": \"#ffec99\",\n \"width\": 35.65440605519484,\n \"height\": 133.00000000000006,\n \"seed\": 1208427085,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710200414381,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": {\n \"elementId\": \"DqHtBlQhJIJJdhiYPYnyx\",\n \"focus\": 0.5210913868097834,\n \"gap\": 18.000000000000057\n },\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -13,\n -101\n ],\n [\n 22.65440605519484,\n -133.00000000000006\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 190,\n \"versionNonce\": 749614285,\n \"isDeleted\": false,\n \"id\": \"DqHtBlQhJIJJdhiYPYnyx\",\n \"fillStyle\": \"cross-hatch\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 756.1343338883071,\n \"y\": 373.11353777244227,\n \"strokeColor\": \"#f08c00\",\n \"backgroundColor\": \"#ffec99\",\n \"width\": 375.26666259765625,\n \"height\": 57.99999999999996,\n \"seed\": 286924333,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [\n {\n \"id\": \"thgsoVvBTFGGTo776yQIY\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710200414381,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 23.19999999999998,\n \"fontFamily\": 1,\n \"text\": \"Total fee is the area\\ngasUsed * (BaseFee + Priority) \",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Total fee is the area\\ngasUsed * (BaseFee + Priority) \",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"arrow\",\n \"version\": 65,\n \"versionNonce\": 1679166083,\n \"isDeleted\": false,\n \"id\": \"WioVA79vE4h71iq_2tbfA\",\n \"fillStyle\": \"cross-hatch\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -264.8656661116931,\n \"y\": -399.88646222755773,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#ffec99\",\n \"width\": 101.00000000000006,\n \"height\": 47,\n \"seed\": 1250958531,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710200414381,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"Kq60_I0edql4zGoSyoChd\",\n \"focus\": 0.6472210590852715,\n \"gap\": 2.1009925512989085\n },\n \"endBinding\": {\n \"elementId\": \"za7W4B5dR7ChlMslpX4wu\",\n \"focus\": -0.06899811772168116,\n \"gap\": 4.66657433195229\n },\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 39.00000000000006,\n 38\n ],\n [\n 101.00000000000006,\n 47\n ]\n ]\n },\n {\n \"type\": \"arrow\",\n \"version\": 730,\n \"versionNonce\": 31415827,\n \"isDeleted\": false,\n \"id\": \"XYc5ZkPR7pwtM_9ZhLFtQ\",\n \"fillStyle\": \"cross-hatch\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dotted\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 605.3522718532689,\n \"y\": 79.9764636975934,\n \"strokeColor\": \"#f08c00\",\n \"backgroundColor\": \"#1e1e1e\",\n \"width\": 124.10839434581175,\n \"height\": 568.6354908692512,\n \"seed\": 2145791469,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710289760051,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": {\n \"elementId\": \"IjNVDD7hxfYKEnov6iTcF\",\n \"focus\": -0.094348463652187,\n \"gap\": 1.8430872982171138\n },\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -52.217937964961834,\n -282.8629259251511\n ],\n [\n -124.10839434581175,\n -568.6354908692512\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 571,\n \"versionNonce\": 1639601853,\n \"isDeleted\": false,\n \"id\": \"2Vo9XjcjeyUZ3jQ8pcT6n\",\n \"fillStyle\": \"cross-hatch\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dotted\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 1.3621548148781173,\n \"x\": 530.855585260547,\n \"y\": -102.47108605543565,\n \"strokeColor\": \"#f08c00\",\n \"backgroundColor\": \"#1e1e1e\",\n \"width\": 138.28334045410156,\n \"height\": 42.13824310429362,\n \"seed\": 1881401421,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [\n {\n \"id\": \"XYc5ZkPR7pwtM_9ZhLFtQ\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710289754334,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 33.710594483434896,\n \"fontFamily\": 1,\n \"text\": \"Because\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Because\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 85,\n \"versionNonce\": 1090673475,\n \"isDeleted\": false,\n \"id\": \"NxMuT1ApN2vymU9rtG5Lp\",\n \"fillStyle\": \"cross-hatch\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 643.1343338883071,\n \"y\": -82.88646222755773,\n \"strokeColor\": \"#2f9e44\",\n \"backgroundColor\": \"#2f9e44\",\n \"width\": 112,\n \"height\": 28,\n \"seed\": 1523939085,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [],\n \"updated\": 1710200448233,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"line\",\n \"version\": 360,\n \"versionNonce\": 1518701197,\n \"isDeleted\": false,\n \"id\": \"EaVQBUTKvuH0oNIyCh44V\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 767.4697245972336,\n \"y\": -324.16051396335496,\n \"strokeColor\": \"#9c36b5\",\n \"backgroundColor\": \"#ffc9c9\",\n \"width\": 216.00000000000003,\n \"height\": 5,\n \"seed\": 700904269,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710200524634,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 216.00000000000003,\n -5\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 348,\n \"versionNonce\": 2045081251,\n \"isDeleted\": false,\n \"id\": \"XggUGQmJppw2m49-MHxId\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 787.4697245972336,\n \"y\": -374.16051396335496,\n \"strokeColor\": \"#be4bdb\",\n \"backgroundColor\": \"#ffc9c9\",\n \"width\": 188.14999389648438,\n \"height\": 45,\n \"seed\": 545587629,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710200520004,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 36,\n \"fontFamily\": 1,\n \"text\": \"Gas used \",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Gas used \",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"arrow\",\n \"version\": 778,\n \"versionNonce\": 1171183549,\n \"isDeleted\": false,\n \"id\": \"eL1EoX6ew8LCBWoJ99CZ_\",\n \"fillStyle\": \"cross-hatch\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 501.74965781147387,\n \"y\": -585.6646513785931,\n \"strokeColor\": \"#2f9e44\",\n \"backgroundColor\": \"#fa5252\",\n \"width\": 274.3853211654411,\n \"height\": 27.34517895541368,\n \"seed\": 78074237,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710289635823,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"PWChet-ElnyP-3U-67gYK\",\n \"focus\": 1.3253732106778702,\n \"gap\": 5.855585651164233\n },\n \"endBinding\": {\n \"elementId\": \"Lr1X3wqk7zltgMGeWJ1NU\",\n \"focus\": 0.7539785926830987,\n \"gap\": 31.047516537031015\n },\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 211.70569922687565,\n -23.601038327941218\n ],\n [\n 274.3853211654411,\n 3.7441406274724613\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 343,\n \"versionNonce\": 792405501,\n \"isDeleted\": false,\n \"id\": \"PWChet-ElnyP-3U-67gYK\",\n \"fillStyle\": \"cross-hatch\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 6.118868396451672,\n \"x\": 535.2510362020209,\n \"y\": -641.34584353458,\n \"strokeColor\": \"#e03131\",\n \"backgroundColor\": \"#fa5252\",\n \"width\": 220.96665954589844,\n \"height\": 25,\n \"seed\": 1176115677,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [\n {\n \"id\": \"eL1EoX6ew8LCBWoJ99CZ_\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710289643913,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 20,\n \"fontFamily\": 1,\n \"text\": \"Max Change GasLimit \",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Max Change GasLimit \",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"line\",\n \"version\": 228,\n \"versionNonce\": 893953843,\n \"isDeleted\": false,\n \"id\": \"DJPX-atFGOyuceaZgKOKl\",\n \"fillStyle\": \"cross-hatch\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0.2559634925863872,\n \"x\": 682.9319951378383,\n \"y\": -601.8098107628223,\n \"strokeColor\": \"#e03131\",\n \"backgroundColor\": \"#fa5252\",\n \"width\": 78.08467856952373,\n \"height\": 39.042339284761866,\n \"seed\": 680874035,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710289632949,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 78.08467856952373,\n -39.042339284761866\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 222,\n \"versionNonce\": 1712001779,\n \"isDeleted\": false,\n \"id\": \"rkBRbI2T2Q3RDg8eBGbav\",\n \"fillStyle\": \"cross-hatch\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 6.073185075025092,\n \"x\": 701.9038900020358,\n \"y\": -611.0407514127423,\n \"strokeColor\": \"#e03131\",\n \"backgroundColor\": \"#fa5252\",\n \"width\": 47.66666793823242,\n \"height\": 25.782676886163497,\n \"seed\": 880988627,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710289794199,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 20.626141508930797,\n \"fontFamily\": 1,\n \"text\": \"1024\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"1024\",\n \"lineHeight\": 1.25\n }\n ],\n \"appState\": {\n \"gridSize\": null,\n \"viewBackgroundColor\": \"#ffffff\"\n },\n \"files\": {}\n}" }, { "path": "docs/images/el-specs/excalidraw/state.excalidraw", "content": "{\n \"type\": \"excalidraw\",\n \"version\": 2,\n \"source\": \"https://excalidraw.com\",\n \"elements\": [\n {\n \"type\": \"rectangle\",\n \"version\": 376,\n \"versionNonce\": 1232377593,\n \"isDeleted\": false,\n \"id\": \"IO9K5731sZw6CRw0dPcOU\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -335.4015395443089,\n \"y\": -2196.920024420023,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 2649.3392684820387,\n \"height\": 1699.378270486243,\n \"seed\": 90773272,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"itHyPYmfj5xzKP2Ow850H\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710062878123,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 541,\n \"versionNonce\": 654258455,\n \"isDeleted\": false,\n \"id\": \"xqKKexpcYgYNl5TB5wUJQ\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1654.305526581535,\n \"y\": -2157.9505851836716,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 628.0333251953125,\n \"height\": 130.5414447067388,\n \"seed\": 86173720,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710062878123,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 104.43315576539102,\n \"fontFamily\": 1,\n \"text\": \"World State\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"World State\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 484,\n \"versionNonce\": 815353817,\n \"isDeleted\": false,\n \"id\": \"G9yxAdOKU0OCETfCg-PFZ\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -231.37514610108974,\n \"y\": -1171.3505463111728,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 467.63327083622664,\n \"height\": 188.95646699487065,\n \"seed\": 702653720,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"r2j3u2WYk4NR_9Z_sWuwQ\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710062878123,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 361,\n \"versionNonce\": 1011283511,\n \"isDeleted\": false,\n \"id\": \"1iqdRN0_1QtYAnBSDAUgA\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -147.8044715925671,\n \"y\": -1116.3919849961183,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 146.81666564941406,\n \"height\": 47.57896650949981,\n \"seed\": 377517080,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710062878123,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 38.063173207599846,\n \"fontFamily\": 1,\n \"text\": \"Address\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Address\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 1109,\n \"versionNonce\": 28299383,\n \"isDeleted\": false,\n \"id\": \"-vxto1xrHUuVB5VzqMLe-\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 739.268137336591,\n \"y\": -1247.0561263558802,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 1166.3819888464157,\n \"height\": 346.9815661505768,\n \"seed\": 2102032152,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"r2j3u2WYk4NR_9Z_sWuwQ\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710062907518,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 834,\n \"versionNonce\": 446240599,\n \"isDeleted\": false,\n \"id\": \"Q13nzqXwVhAxiqLK80EwV\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 777.5727630441054,\n \"y\": -1200.6629820699727,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 534.1333618164062,\n \"height\": 76.28472300274863,\n \"seed\": 1823768,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710062878123,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 61.02777840219891,\n \"fontFamily\": 1,\n \"text\": \"2. Account State\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"2. Account State\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"text\",\n \"version\": 293,\n \"versionNonce\": 1218964889,\n \"isDeleted\": false,\n \"id\": \"uO5xgQsmf8r6tdlGnej67\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 60,\n \"angle\": 0,\n \"x\": -23.322359214651897,\n \"y\": -1064.7348213572332,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 227.21665954589844,\n \"height\": 47.57896650949981,\n \"seed\": 1317372488,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710062878123,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 38.063173207599846,\n \"fontFamily\": 1,\n \"text\": \"(160 bit ID)\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"(160 bit ID)\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"text\",\n \"version\": 459,\n \"versionNonce\": 1749685367,\n \"isDeleted\": false,\n \"id\": \"keHGB7EfrWA1mWCGhIVoJ\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 60,\n \"angle\": 0,\n \"x\": 713.9897884631764,\n \"y\": -1070.8844836951957,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 1185.9666748046875,\n \"height\": 57.58985626508537,\n \"seed\": 677592120,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [\n {\n \"id\": \"r2j3u2WYk4NR_9Z_sWuwQ\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710062878123,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 46.0718850120683,\n \"fontFamily\": 1,\n \"text\": \" nonce balance storageRoot codeHash \",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \" nonce balance storageRoot codeHash \",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 290,\n \"versionNonce\": 1013722905,\n \"isDeleted\": false,\n \"id\": \"-fDoiVhU2kgl4K-qZL6LR\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 60,\n \"angle\": 0,\n \"x\": 1609.251158294988,\n \"y\": -1003.8855308552877,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 267.9378099926725,\n \"height\": 71.17295694078547,\n \"seed\": 661269304,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"Xsi3_ZASB1wXu247b4V3y\"\n }\n ],\n \"updated\": 1710062902727,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 336,\n \"versionNonce\": 1831396345,\n \"isDeleted\": false,\n \"id\": \"Xsi3_ZASB1wXu247b4V3y\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 60,\n \"angle\": 0,\n \"x\": 1665.7200632913243,\n \"y\": -998.8855308552877,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 155,\n \"height\": 61.17295694078546,\n \"seed\": 1091902520,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710062902728,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 48.93836555262837,\n \"fontFamily\": 1,\n \"text\": \"Kec(())\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"-fDoiVhU2kgl4K-qZL6LR\",\n \"originalText\": \"Kec(())\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"arrow\",\n \"version\": 478,\n \"versionNonce\": 746199897,\n \"isDeleted\": false,\n \"id\": \"v3xKeD88t-b8aCaLumZxf\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 60,\n \"angle\": 0,\n \"x\": 1708.2930885800688,\n \"y\": -959.2195622953492,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 114.5779193494076,\n \"height\": 214.4321477743388,\n \"seed\": 115369800,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878123,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": {\n \"elementId\": \"VfA7i9sR5pZQb57CQL3Wv\",\n \"focus\": -0.8787839598566589,\n \"gap\": 11.651991798244467\n },\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 15.535989064326644,\n 141.7659002119789\n ],\n [\n 114.5779193494076,\n 214.4321477743388\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 291,\n \"versionNonce\": 72000183,\n \"isDeleted\": false,\n \"id\": \"VfA7i9sR5pZQb57CQL3Wv\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 60,\n \"angle\": 0,\n \"x\": 1834.5229997277208,\n \"y\": -778.6136894225544,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 339.29998779296875,\n \"height\": 61.17295694078546,\n \"seed\": 1986897464,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [\n {\n \"id\": \"v3xKeD88t-b8aCaLumZxf\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710062878123,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 48.93836555262837,\n \"fontFamily\": 1,\n \"text\": \"simple-account\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"simple-account\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 382,\n \"versionNonce\": 892291129,\n \"isDeleted\": false,\n \"id\": \"v0t3HbLARpqWeH0dz-Y7I\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -471.4940880033814,\n \"y\": -262.76895255808347,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 73.7988155422428,\n \"height\": 42.34358268817212,\n \"seed\": 1080620088,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [],\n \"updated\": 1710062878123,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"rectangle\",\n \"version\": 498,\n \"versionNonce\": 1853043671,\n \"isDeleted\": false,\n \"id\": \"ZEbsCM3VO8LQpcqmhLm0v\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -245.86328310783574,\n \"y\": -265.7934941786673,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 68.95954894930885,\n \"height\": 39.923949391705115,\n \"seed\": 812997944,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [],\n \"updated\": 1710062878123,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"rectangle\",\n \"version\": 378,\n \"versionNonce\": 1282136345,\n \"isDeleted\": false,\n \"id\": \"ndTkoQwE_Gry_xJky-NNp\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -578.8653155341037,\n \"y\": -128.78175876622464,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 73.7988155422428,\n \"height\": 42.34358268817212,\n \"seed\": 1921501768,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [],\n \"updated\": 1710062878123,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"rectangle\",\n \"version\": 507,\n \"versionNonce\": 1672257783,\n \"isDeleted\": false,\n \"id\": \"LIbJVOR-OCtrku7_In_xd\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -402.83699321613096,\n \"y\": -119.70813390447324,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 68.95954894930885,\n \"height\": 39.923949391705115,\n \"seed\": 849822024,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [],\n \"updated\": 1710062878123,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"rectangle\",\n \"version\": 441,\n \"versionNonce\": 1940082169,\n \"isDeleted\": false,\n \"id\": \"Ul8wZazOmgbEClAWHEjHq\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -300.6074864404011,\n \"y\": -122.73267552505706,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 73.7988155422428,\n \"height\": 42.34358268817212,\n \"seed\": 2133584184,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [],\n \"updated\": 1710062878123,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"rectangle\",\n \"version\": 581,\n \"versionNonce\": 91974167,\n \"isDeleted\": false,\n \"id\": \"1dLU3kRYRRxWSe-pawF2c\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -176.6012799964683,\n \"y\": -117.28850060800619,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 68.95954894930885,\n \"height\": 39.923949391705115,\n \"seed\": 1162478136,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [],\n \"updated\": 1710062878123,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"line\",\n \"version\": 389,\n \"versionNonce\": 836314841,\n \"isDeleted\": false,\n \"id\": \"bKQAhktV4UTmylTpNAyJy\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -467.86463805868095,\n \"y\": -227.68426975931197,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 82.26753207987724,\n \"height\": 102.8344150998465,\n \"seed\": 142804536,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878123,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -82.26753207987724,\n 102.8344150998465\n ]\n ]\n },\n {\n \"type\": \"line\",\n \"version\": 385,\n \"versionNonce\": 1356074807,\n \"isDeleted\": false,\n \"id\": \"tnTXZUy_h-lOJgihk4pS-\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -403.74435570230617,\n \"y\": -224.05481981461196,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 31.45523285407074,\n \"height\": 95.57551521044567,\n \"seed\": 1356500280,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878123,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 31.45523285407074,\n 95.57551521044567\n ]\n ]\n },\n {\n \"type\": \"line\",\n \"version\": 339,\n \"versionNonce\": 1637934009,\n \"isDeleted\": false,\n \"id\": \"w2sWAC26Pocw-UYxWcstL\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -221.06204181904923,\n \"y\": -231.31371970401256,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 53.2319325222735,\n \"height\": 108.88349834101392,\n \"seed\": 1012303928,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878123,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -53.2319325222735,\n 108.88349834101392\n ]\n ]\n },\n {\n \"type\": \"line\",\n \"version\": 379,\n \"versionNonce\": 807080023,\n \"isDeleted\": false,\n \"id\": \"VB1DolnqTnWZzHpKG9n51\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -195.65589220614606,\n \"y\": -228.89408640754573,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 49.60248257757304,\n \"height\": 107.6736816927805,\n \"seed\": 1440386120,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878123,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 49.60248257757304,\n 107.6736816927805\n ]\n ]\n },\n {\n \"type\": \"line\",\n \"version\": 352,\n \"versionNonce\": 1058931865,\n \"isDeleted\": false,\n \"id\": \"h6nRltsQOcR-yQTX25Odb\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -394.0658225164382,\n \"y\": -243.4118861863476,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 152.4368976774197,\n \"height\": 1.2098166482334067,\n \"seed\": 1239308344,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878123,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 152.4368976774197,\n -1.2098166482334067\n ]\n ]\n },\n {\n \"type\": \"rectangle\",\n \"version\": 425,\n \"versionNonce\": 1234178265,\n \"isDeleted\": false,\n \"id\": \"XIM1PQOLXyKeiQq5c1ppz\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dotted\",\n \"roughness\": 2,\n \"opacity\": 60,\n \"angle\": 0,\n \"x\": 1195.3397843854143,\n \"y\": -860.6888999516077,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 118.46191661548927,\n \"height\": 67.96995215642829,\n \"seed\": 1435478088,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"GRruvfbPnVTyoVbcu80Y4\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"cHjRVNWgYW_dIdh5bfz0w\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710062937585,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"rectangle\",\n \"version\": 529,\n \"versionNonce\": 64751609,\n \"isDeleted\": false,\n \"id\": \"UWbI_IUte3HTFlmJ6BQar\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dotted\",\n \"roughness\": 2,\n \"opacity\": 60,\n \"angle\": 0,\n \"x\": 1557.5225294475254,\n \"y\": -865.5438965342096,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 110.69392208332602,\n \"height\": 64.08595489034663,\n \"seed\": 1694719816,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"LIwWHqRa_eTXVeu9tGuHS\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710062890677,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"rectangle\",\n \"version\": 475,\n \"versionNonce\": 2118060537,\n \"isDeleted\": false,\n \"id\": \"mJ5QIrDSyZPcRv6GIm5fC\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dotted\",\n \"roughness\": 2,\n \"opacity\": 60,\n \"angle\": 0,\n \"x\": 1071.2767144311106,\n \"y\": -687.4811756332697,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 118.46191661548927,\n \"height\": 67.96995215642829,\n \"seed\": 1525167688,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"cHjRVNWgYW_dIdh5bfz0w\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710062931895,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"rectangle\",\n \"version\": 549,\n \"versionNonce\": 252691321,\n \"isDeleted\": false,\n \"id\": \"UnYuQrX7RplluKb2SjBhT\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dotted\",\n \"roughness\": 2,\n \"opacity\": 60,\n \"angle\": 0,\n \"x\": 1340.5041822052149,\n \"y\": -691.2495192187969,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 110.69392208332602,\n \"height\": 64.08595489034663,\n \"seed\": 203042120,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [],\n \"updated\": 1710062890677,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"rectangle\",\n \"version\": 482,\n \"versionNonce\": 1662708825,\n \"isDeleted\": false,\n \"id\": \"lLLqDhs8wDW1lWQ53NzxR\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dotted\",\n \"roughness\": 2,\n \"opacity\": 60,\n \"angle\": 0,\n \"x\": 1504.6030666971635,\n \"y\": -696.1045158013987,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 118.46191661548927,\n \"height\": 67.96995215642829,\n \"seed\": 1375028296,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"OBcTCD6lQPFiwzXAKNem5\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710062890677,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"rectangle\",\n \"version\": 626,\n \"versionNonce\": 1003252249,\n \"isDeleted\": false,\n \"id\": \"frnkG3w7AIaJYgXN8zUHF\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dotted\",\n \"roughness\": 2,\n \"opacity\": 60,\n \"angle\": 0,\n \"x\": 1685.5326060087987,\n \"y\": -690.7640195605361,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 110.69392208332602,\n \"height\": 64.08595489034663,\n \"seed\": 2052422472,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"kLKBA3VC842f3KxQfOq-_\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710062890677,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"line\",\n \"version\": 387,\n \"versionNonce\": 2097772505,\n \"isDeleted\": false,\n \"id\": \"OAF6ZEL194fG8t2ZCRT9g\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dotted\",\n \"roughness\": 2,\n \"opacity\": 60,\n \"angle\": 0,\n \"x\": 1319.627696900026,\n \"y\": -829.6169218229544,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 244.6918277631419,\n \"height\": 1.9419986330406758,\n \"seed\": 706178632,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062890677,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 244.6918277631419,\n -1.9419986330406758\n ]\n ]\n },\n {\n \"type\": \"rectangle\",\n \"version\": 330,\n \"versionNonce\": 1688147129,\n \"isDeleted\": false,\n \"id\": \"vomWTYwSmWFPmUuNrmOEz\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 60,\n \"angle\": 0,\n \"x\": 1315.7436996339443,\n \"y\": -1008.8135527266346,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 217.2138400657745,\n \"height\": 71.17295694078547,\n \"seed\": 1270444088,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"9ohaM2_szdA0az7lGVUaf\"\n }\n ],\n \"updated\": 1710062890677,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 416,\n \"versionNonce\": 86906265,\n \"isDeleted\": false,\n \"id\": \"9ohaM2_szdA0az7lGVUaf\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 60,\n \"angle\": 0,\n \"x\": 1366.8172868421245,\n \"y\": -1003.8135527266346,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 115.06666564941406,\n \"height\": 61.17295694078546,\n \"seed\": 678113352,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710062890677,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 48.93836555262837,\n \"fontFamily\": 1,\n \"text\": \"Root\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"vomWTYwSmWFPmUuNrmOEz\",\n \"originalText\": \"Root\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"arrow\",\n \"version\": 680,\n \"versionNonce\": 1349202809,\n \"isDeleted\": false,\n \"id\": \"cHjRVNWgYW_dIdh5bfz0w\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 2,\n \"opacity\": 60,\n \"angle\": 0,\n \"x\": 1130.2609943362575,\n \"y\": -692.9194182858641,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 111.9620892085104,\n \"height\": 99.34661198829872,\n \"seed\": 1974019656,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062938108,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"mJ5QIrDSyZPcRv6GIm5fC\",\n \"focus\": -0.4580677464498961,\n \"gap\": 5.438242652594454\n },\n \"endBinding\": {\n \"elementId\": \"XIM1PQOLXyKeiQq5c1ppz\",\n \"focus\": -0.2713309299747085,\n \"gap\": 1\n },\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 111.9620892085104,\n -99.34661198829872\n ]\n ]\n },\n {\n \"type\": \"arrow\",\n \"version\": 898,\n \"versionNonce\": 1268138841,\n \"isDeleted\": false,\n \"id\": \"CMjGwh8ThfbgGZf40eLwl\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 2,\n \"opacity\": 60,\n \"angle\": 0,\n \"x\": 1327.157789393378,\n \"y\": -712.3687543531158,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 69.45476219540723,\n \"height\": 89.18628722239949,\n \"seed\": 770387784,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062890677,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -69.45476219540723,\n -89.18628722239949\n ]\n ]\n },\n {\n \"type\": \"arrow\",\n \"version\": 651,\n \"versionNonce\": 161301879,\n \"isDeleted\": false,\n \"id\": \"OBcTCD6lQPFiwzXAKNem5\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 2,\n \"opacity\": 60,\n \"angle\": 0,\n \"x\": 1530.4903998991085,\n \"y\": -708.4847570870345,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 76.55309469095747,\n \"height\": 99.04193028508064,\n \"seed\": 223969864,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062892198,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"lLLqDhs8wDW1lWQ53NzxR\",\n \"focus\": -0.8091420651756261,\n \"gap\": 12.380241285635748\n },\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 76.55309469095747,\n -99.04193028508064\n ]\n ]\n },\n {\n \"type\": \"arrow\",\n \"version\": 692,\n \"versionNonce\": 1591967383,\n \"isDeleted\": false,\n \"id\": \"kLKBA3VC842f3KxQfOq-_\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 2,\n \"opacity\": 60,\n \"angle\": 0,\n \"x\": 1725.5847789354366,\n \"y\": -700.6222485435388,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 102.12360477026388,\n \"height\": 107.3899384868369,\n \"seed\": 1416777288,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062892199,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"frnkG3w7AIaJYgXN8zUHF\",\n \"focus\": 0.2860873772844371,\n \"gap\": 9.858228983002789\n },\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -102.12360477026388,\n -107.3899384868369\n ]\n ]\n },\n {\n \"type\": \"arrow\",\n \"version\": 639,\n \"versionNonce\": 1564840887,\n \"isDeleted\": false,\n \"id\": \"GRruvfbPnVTyoVbcu80Y4\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 60,\n \"angle\": 0,\n \"x\": 1280.6703219515139,\n \"y\": -873.5546408955029,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 106.92732710494082,\n \"height\": 66.02795352338761,\n \"seed\": 411450424,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062892200,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"XIM1PQOLXyKeiQq5c1ppz\",\n \"focus\": -0.43557294063506097,\n \"gap\": 12.865740943895162\n },\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 106.92732710494082,\n -66.02795352338761\n ]\n ]\n },\n {\n \"type\": \"arrow\",\n \"version\": 669,\n \"versionNonce\": 753403095,\n \"isDeleted\": false,\n \"id\": \"LIwWHqRa_eTXVeu9tGuHS\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 60,\n \"angle\": 0,\n \"x\": 1589.2171387370222,\n \"y\": -871.6126422624623,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 118.11354845981325,\n \"height\": 71.85394942250996,\n \"seed\": 1764598600,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062892200,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"UWbI_IUte3HTFlmJ6BQar\",\n \"focus\": 0.3610071718116607,\n \"gap\": 6.068745728252736\n },\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -118.11354845981325,\n -71.85394942250996\n ]\n ]\n },\n {\n \"type\": \"rectangle\",\n \"version\": 740,\n \"versionNonce\": 1556945817,\n \"isDeleted\": false,\n \"id\": \"YgTNG4mMDgxd05RP73FvI\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 5.973411447994389,\n \"x\": 311.406785825038,\n \"y\": -266.0030951688411,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 187.80342740713817,\n \"height\": 107.75606490573506,\n \"seed\": 999027000,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"A6ssw4KZLD-sXjoV1S0K8\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710062878124,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"rectangle\",\n \"version\": 845,\n \"versionNonce\": 1993786999,\n \"isDeleted\": false,\n \"id\": \"CEs9pAMiNSOgrX_dnxYwl\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 5.973411447994389,\n \"x\": 855.2710897444767,\n \"y\": -446.3466984362551,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 175.48844856076846,\n \"height\": 101.59857548255013,\n \"seed\": 141101624,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"99aEwiK-e7X9W5rjBS_yZ\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"wSBYi4tPw8ZCjV59YCzQw\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710062878124,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"rectangle\",\n \"version\": 763,\n \"versionNonce\": 465059961,\n \"isDeleted\": false,\n \"id\": \"I1ttxVApENuMPqkqC-D99\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"dotted\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 5.973411447994389,\n \"x\": 146.28386359720218,\n \"y\": -17.21810382517097,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 187.80342740713817,\n \"height\": 107.75606490573506,\n \"seed\": 1278935864,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"A7Jw5nfZEmhu5hg-jX0Do\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710062878124,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"rectangle\",\n \"version\": 885,\n \"versionNonce\": 1262804887,\n \"isDeleted\": false,\n \"id\": \"pIN36-tSs7QMrHMsmmsnd\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"dotted\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 5.973411447994389,\n \"x\": 590.9798055751871,\n \"y\": -124.75974605207847,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 175.48844856076846,\n \"height\": 101.59857548255013,\n \"seed\": 358997048,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"A6ssw4KZLD-sXjoV1S0K8\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710062878124,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"rectangle\",\n \"version\": 810,\n \"versionNonce\": 531351897,\n \"isDeleted\": false,\n \"id\": \"ltCFgPznzfUFQbMuS5Tks\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"dotted\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 5.973411447994389,\n \"x\": 825.3835158996335,\n \"y\": -218.42003975813324,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 187.80342740713817,\n \"height\": 107.75606490573506,\n \"seed\": 97359160,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"99aEwiK-e7X9W5rjBS_yZ\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710062878124,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"rectangle\",\n \"version\": 918,\n \"versionNonce\": 1490212023,\n \"isDeleted\": false,\n \"id\": \"K5UwfdasHG5mZjeNcCXhz\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"dotted\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 5.973411447994389,\n \"x\": 1099.2821619767892,\n \"y\": -291.93727602058595,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 175.97511080804617,\n \"height\": 101.88032730992144,\n \"seed\": 1658203704,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"wSBYi4tPw8ZCjV59YCzQw\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710062878124,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"line\",\n \"version\": 700,\n \"versionNonce\": 1912288825,\n \"isDeleted\": false,\n \"id\": \"RpGa4xt3vaf-11cP40y-0\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 5.973411447994389,\n \"x\": 492.5615126716019,\n \"y\": -307.0345711915144,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 387.92183366064637,\n \"height\": 3.07874471159222,\n \"seed\": 627287864,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878124,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 387.92183366064637,\n -3.07874471159222\n ]\n ]\n },\n {\n \"type\": \"arrow\",\n \"version\": 1390,\n \"versionNonce\": 656745943,\n \"isDeleted\": false,\n \"id\": \"A7Jw5nfZEmhu5hg-jX0Do\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 5.973411447994389,\n \"x\": 275.3072911447004,\n \"y\": -60.88440427916173,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 144.71644882405485,\n \"height\": 76.5417210816725,\n \"seed\": 1536250424,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878124,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"I1ttxVApENuMPqkqC-D99\",\n \"focus\": -0.19623168178646233,\n \"gap\": 4.2332739784393\n },\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 144.71644882405485,\n -76.5417210816725\n ]\n ]\n },\n {\n \"type\": \"arrow\",\n \"version\": 2272,\n \"versionNonce\": 629802777,\n \"isDeleted\": false,\n \"id\": \"A6ssw4KZLD-sXjoV1S0K8\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 5.973411447994389,\n \"x\": 586.7324422805201,\n \"y\": -87.64645693897427,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 107.95314310500436,\n \"height\": 91.08763691023753,\n \"seed\": 588925752,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878124,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"pIN36-tSs7QMrHMsmmsnd\",\n \"focus\": -0.009621595725947684,\n \"gap\": 4.529335007809408\n },\n \"endBinding\": {\n \"elementId\": \"YgTNG4mMDgxd05RP73FvI\",\n \"focus\": 0.2400847825873511,\n \"gap\": 14.642910476457871\n },\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -107.95314310500436,\n -91.08763691023753\n ]\n ]\n },\n {\n \"type\": \"arrow\",\n \"version\": 1439,\n \"versionNonce\": 1431327479,\n \"isDeleted\": false,\n \"id\": \"99aEwiK-e7X9W5rjBS_yZ\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 5.973411447994389,\n \"x\": 884.4322209385625,\n \"y\": -231.29781825168283,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 69.03461469614581,\n \"height\": 89.13821017525069,\n \"seed\": 1629234232,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878124,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"ltCFgPznzfUFQbMuS5Tks\",\n \"focus\": -0.35536244310549625,\n \"gap\": 7.312018690032005\n },\n \"endBinding\": {\n \"elementId\": \"CEs9pAMiNSOgrX_dnxYwl\",\n \"focus\": -0.1854629250416917,\n \"gap\": 11.648625510212696\n },\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 69.03461469614581,\n -89.13821017525069\n ]\n ]\n },\n {\n \"type\": \"arrow\",\n \"version\": 1582,\n \"versionNonce\": 617331705,\n \"isDeleted\": false,\n \"id\": \"wSBYi4tPw8ZCjV59YCzQw\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 5.973411447994389,\n \"x\": 1146.846606062589,\n \"y\": -273.2052120619973,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 113.86655744288737,\n \"height\": 93.21235429685413,\n \"seed\": 326819128,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878124,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"K5UwfdasHG5mZjeNcCXhz\",\n \"focus\": 0.3915561393118875,\n \"gap\": 7.2189952918269\n },\n \"endBinding\": {\n \"elementId\": \"CEs9pAMiNSOgrX_dnxYwl\",\n \"focus\": 0.17647097962003544,\n \"gap\": 19.48260476170492\n },\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -113.86655744288737,\n -93.21235429685413\n ]\n ]\n },\n {\n \"type\": \"ellipse\",\n \"version\": 370,\n \"versionNonce\": 735632407,\n \"isDeleted\": false,\n \"id\": \"1oRh6mr94wfriT9njbbK-\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -1328.195832072577,\n \"y\": -353.6063732443762,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 361.1228196486118,\n \"height\": 73.48429469593847,\n \"seed\": 833117752,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878124,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"ellipse\",\n \"version\": 439,\n \"versionNonce\": 1069798617,\n \"isDeleted\": false,\n \"id\": \"I1h988mfe3GlfBaAN32sv\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -1328.5457572854148,\n \"y\": -150.29982458561346,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 361.1228196486118,\n \"height\": 73.48429469593847,\n \"seed\": 1838689608,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878124,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"line\",\n \"version\": 390,\n \"versionNonce\": 1857241399,\n \"isDeleted\": false,\n \"id\": \"E6FSca6E-lEhIFFCZg0cL\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -973.7215914678834,\n \"y\": -317.91400153492043,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 0,\n \"height\": 214.154230256735,\n \"seed\": 1385424184,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878124,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 0,\n 214.154230256735\n ]\n ]\n },\n {\n \"type\": \"line\",\n \"version\": 387,\n \"versionNonce\": 2047201721,\n \"isDeleted\": false,\n \"id\": \"-Zi3PQEi-drsMxvRiR_5T\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -1325.3964303698745,\n \"y\": -310.9154972781645,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 3.4992521283780627,\n \"height\": 192.45886706079116,\n \"seed\": 502710840,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878124,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -3.4992521283780627,\n 192.45886706079116\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 336,\n \"versionNonce\": 1866728023,\n \"isDeleted\": false,\n \"id\": \"-jKHYNk_8V6jX7dTwigpI\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -1240.7145288631268,\n \"y\": -233.93195045384783,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 187.4499969482422,\n \"height\": 47.239903733103304,\n \"seed\": 1481072440,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710062878124,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 37.791922986482646,\n \"fontFamily\": 1,\n \"text\": \"State DB\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"State DB\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"arrow\",\n \"version\": 466,\n \"versionNonce\": 414528153,\n \"isDeleted\": false,\n \"id\": \"EzQPD-S0Z_kNojS1czb8O\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 60,\n \"angle\": 0,\n \"x\": -682.675072461958,\n \"y\": -208.85222773140453,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 283.9110081241227,\n \"height\": 0,\n \"seed\": 2022032712,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878124,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"yxabqq0rH84BfUbZ3cQUa\",\n \"focus\": 0.09501252003393289,\n \"gap\": 26.088991875877355\n },\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -283.9110081241227,\n 0\n ]\n ]\n },\n {\n \"type\": \"arrow\",\n \"version\": 580,\n \"versionNonce\": 1583325047,\n \"isDeleted\": false,\n \"id\": \"pko9jThYHExG3FyK8LVDp\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 60,\n \"angle\": 0,\n \"x\": -1.5860805860796745,\n \"y\": -224.6954528669716,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 1318.333333333333,\n \"height\": 719.796000124481,\n \"seed\": 1691971640,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878124,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"yxabqq0rH84BfUbZ3cQUa\",\n \"focus\": 0.31360162849846296,\n \"gap\": 5.000000000001023\n },\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 875.0000000000001,\n -366.4626667911478\n ],\n [\n 1318.333333333333,\n -719.796000124481\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 348,\n \"versionNonce\": 1887795065,\n \"isDeleted\": false,\n \"id\": \"hnokLxgKNy0QCgoj2wB-w\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 5.907648648251377,\n \"x\": 266.54608220475046,\n \"y\": -486.0749976755806,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 268.1833190917969,\n \"height\": 66.79646370944386,\n \"seed\": 1464906808,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 53.43717096755508,\n \"fontFamily\": 1,\n \"text\": \"1. Collapse\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"1. Collapse\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"arrow\",\n \"version\": 356,\n \"versionNonce\": 1851022583,\n \"isDeleted\": false,\n \"id\": \"r2j3u2WYk4NR_9Z_sWuwQ\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 60,\n \"angle\": 0,\n \"x\": 251.4704473606234,\n \"y\": -1048.5959897018595,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 473.52400002311686,\n \"height\": 2.0750146605673763,\n \"seed\": 1122196024,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062907537,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"G9yxAdOKU0OCETfCg-PFZ\",\n \"gap\": 15.212322625486536,\n \"focus\": 0.3080947096885752\n },\n \"endBinding\": {\n \"elementId\": \"-vxto1xrHUuVB5VzqMLe-\",\n \"gap\": 14.273689952850532,\n \"focus\": -0.11517538323192285\n },\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 473.52400002311686,\n -2.0750146605673763\n ]\n ]\n },\n {\n \"type\": \"rectangle\",\n \"version\": 915,\n \"versionNonce\": 1941577817,\n \"isDeleted\": false,\n \"id\": \"Z29hbbjctpbYdY0VxyccT\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -185.45984168145515,\n \"y\": -1965.7044018603058,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 407.4825354803077,\n \"height\": 164.65137334814762,\n \"seed\": 602800712,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"vxw99ltFtHWJGd6QDlUf9\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 772,\n \"versionNonce\": 1421438391,\n \"isDeleted\": false,\n \"id\": \"KtD4RQ6907q89W-Tc6lsG\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -95.64620838970723,\n \"y\": -1917.815050722048,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 127.93333435058594,\n \"height\": 41.458978900612706,\n \"seed\": 1250326856,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 33.167183120490165,\n \"fontFamily\": 1,\n \"text\": \"Address\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Address\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 1485,\n \"versionNonce\": 2534713,\n \"isDeleted\": false,\n \"id\": \"vocf8cWUwEKcFrwriCsYS\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 789.3826964707464,\n \"y\": -2011.281138423264,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 1106.256833750648,\n \"height\": 342.20726293139546,\n \"seed\": 351801416,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"vxw99ltFtHWJGd6QDlUf9\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 1231,\n \"versionNonce\": 2094046935,\n \"isDeleted\": false,\n \"id\": \"wtoCJgw8sIcxfiFc2Q-YL\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 824.8570056497792,\n \"y\": -1970.8194276249312,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 402.9333190917969,\n \"height\": 69.32113520662963,\n \"seed\": 1797179208,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 55.45690816530371,\n \"fontFamily\": 1,\n \"text\": \"Account State\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Account State\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"text\",\n \"version\": 704,\n \"versionNonce\": 1831771673,\n \"isDeleted\": false,\n \"id\": \"Cb2mTewhVqzShWUeYH_tf\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 60,\n \"angle\": 0,\n \"x\": 12.824018040058945,\n \"y\": -1872.8024450585258,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 197.98333740234375,\n \"height\": 41.458978900612706,\n \"seed\": 1498848840,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 33.167183120490165,\n \"fontFamily\": 1,\n \"text\": \"(160 bit ID)\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"(160 bit ID)\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"text\",\n \"version\": 859,\n \"versionNonce\": 958704631,\n \"isDeleted\": false,\n \"id\": \"v3vHX39_JuGVZXm9a5eQc\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 60,\n \"angle\": 0,\n \"x\": 764.0490975148059,\n \"y\": -1855.9167048117843,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 1077.816650390625,\n \"height\": 52.332813904803814,\n \"seed\": 8099144,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [\n {\n \"id\": \"vxw99ltFtHWJGd6QDlUf9\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 41.86625112384305,\n \"fontFamily\": 1,\n \"text\": \" nonce balance storageRoot codeHash \",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \" nonce balance storageRoot codeHash \",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"arrow\",\n \"version\": 1933,\n \"versionNonce\": 1506112249,\n \"isDeleted\": false,\n \"id\": \"vxw99ltFtHWJGd6QDlUf9\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 60,\n \"angle\": 0,\n \"x\": 235.2782856922463,\n \"y\": -1850.1442163726856,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 548.4637123239592,\n \"height\": 4.824371538394582,\n \"seed\": 1395476552,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"Z29hbbjctpbYdY0VxyccT\",\n \"focus\": 0.37240335703956057,\n \"gap\": 13.255591893393728\n },\n \"endBinding\": {\n \"elementId\": \"vocf8cWUwEKcFrwriCsYS\",\n \"focus\": 0.0012918092222106296,\n \"gap\": 5.640698454541052\n },\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 548.4637123239592,\n 4.824371538394582\n ]\n ]\n },\n {\n \"type\": \"rectangle\",\n \"version\": 396,\n \"versionNonce\": 632952087,\n \"isDeleted\": false,\n \"id\": \"asKtU7pgA49Ln2HBJpo34\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 60,\n \"angle\": 0,\n \"x\": 1576.2782352513227,\n \"y\": -1793.8562900909865,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 281.16882505749913,\n \"height\": 87.42223972375996,\n \"seed\": 186167352,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"vPn4KNpRUkhYFSVR3AkOA\"\n },\n {\n \"id\": \"X0yr_NSvQVSACw2-yB01S\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 495,\n \"versionNonce\": 980331481,\n \"isDeleted\": false,\n \"id\": \"vPn4KNpRUkhYFSVR3AkOA\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 60,\n \"angle\": 0,\n \"x\": 1599.820983656537,\n \"y\": -1782.0424739121,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 234.0833282470703,\n \"height\": 63.79460736598691,\n \"seed\": 489854776,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 51.03568589278953,\n \"fontFamily\": 1,\n \"text\": \"Kec(code)\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"asKtU7pgA49Ln2HBJpo34\",\n \"originalText\": \"Kec(code)\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"arrow\",\n \"version\": 853,\n \"versionNonce\": 1778735671,\n \"isDeleted\": false,\n \"id\": \"X0yr_NSvQVSACw2-yB01S\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 60,\n \"angle\": 0,\n \"x\": 1699.1419235117423,\n \"y\": -1701.708523895673,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 276.44329858594267,\n \"height\": 63.74277795511615,\n \"seed\": 774443336,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"asKtU7pgA49Ln2HBJpo34\",\n \"focus\": 0.5249500998003894,\n \"gap\": 4.725526471553621\n },\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 103.96158237420047,\n 47.25526471554576\n ],\n [\n 276.44329858594267,\n 63.74277795511615\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 294,\n \"versionNonce\": 658360505,\n \"isDeleted\": false,\n \"id\": \"1WnSiFI9D_wX_Ob0kqXo7\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 60,\n \"angle\": 0,\n \"x\": 1952.9849163432107,\n \"y\": -1684.9768181065826,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 215.01666259765625,\n \"height\": 122.34591388157092,\n \"seed\": 1502426936,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 48.93836555262837,\n \"fontFamily\": 1,\n \"text\": \"Contract\\nAccount\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Contract\\nAccount\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"ellipse\",\n \"version\": 288,\n \"versionNonce\": 1256913751,\n \"isDeleted\": false,\n \"id\": \"xkJeWprZ5Ow_LfY8RGrnd\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 40,\n \"angle\": 0,\n \"x\": 519.057416902772,\n \"y\": -1785.7989138052847,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#1e1e1e\",\n \"width\": 33.74648501801634,\n \"height\": 29.77631031001452,\n \"seed\": 2083093304,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"ellipse\",\n \"version\": 369,\n \"versionNonce\": 1775651225,\n \"isDeleted\": false,\n \"id\": \"uz6YcF5ADpJUL2FU56R5L\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 80,\n \"angle\": 0,\n \"x\": 520.3305382976532,\n \"y\": -1685.573045757078,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#1e1e1e\",\n \"width\": 33.74648501801634,\n \"height\": 29.77631031001452,\n \"seed\": 1140663368,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"ellipse\",\n \"version\": 354,\n \"versionNonce\": 2092922999,\n \"isDeleted\": false,\n \"id\": \"HbahmW6aRq8uNGqt901N_\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 40,\n \"angle\": 0,\n \"x\": 517.6983685817913,\n \"y\": -1377.4092773772716,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#1e1e1e\",\n \"width\": 33.74648501801634,\n \"height\": 29.77631031001452,\n \"seed\": 319268920,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"ellipse\",\n \"version\": 410,\n \"versionNonce\": 1265348217,\n \"isDeleted\": false,\n \"id\": \"hZvGF0XiWGbeUx9srSsMI\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 80,\n \"angle\": 0,\n \"x\": 520.9565773306724,\n \"y\": -1262.1865303083794,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#1e1e1e\",\n \"width\": 33.74648501801634,\n \"height\": 29.77631031001452,\n \"seed\": 89514296,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"rectangle\",\n \"version\": 997,\n \"versionNonce\": 893866391,\n \"isDeleted\": false,\n \"id\": \"kRNVuNuBdXnpYZPpjEk0D\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -222.44843401499202,\n \"y\": -1502.5184307977506,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 474.43026605186947,\n \"height\": 87.48233396443534,\n \"seed\": 764740168,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"tq3ElJ69jp4rnBi2WYBFQ\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 842,\n \"versionNonce\": 583104345,\n \"isDeleted\": false,\n \"id\": \"aAxpbF_leMJUMBP0BLNir\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -108.20942353555529,\n \"y\": -1487.19724710548,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 188.73333740234375,\n \"height\": 61.17295694078546,\n \"seed\": 122517832,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 48.93836555262837,\n \"fontFamily\": 1,\n \"text\": \"Address\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Address\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"text\",\n \"version\": 1247,\n \"versionNonce\": 2109146807,\n \"isDeleted\": false,\n \"id\": \"VvqpZglNwpgM3Yhfdwxd2\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1161.4018802520106,\n \"y\": -1473.6407762938672,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 443.45001220703125,\n \"height\": 76.28472300274863,\n \"seed\": 551489608,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [\n {\n \"id\": \"cWBRzb344iWZURPu1ik5n\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 61.02777840219891,\n \"fontFamily\": 1,\n \"text\": \"Account State\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Account State\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"arrow\",\n \"version\": 1988,\n \"versionNonce\": 573252665,\n \"isDeleted\": false,\n \"id\": \"tq3ElJ69jp4rnBi2WYBFQ\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 60,\n \"angle\": 0,\n \"x\": 267.19415466236524,\n \"y\": -1444.3229089997874,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 802.0454354458544,\n \"height\": 2.6574234155678584,\n \"seed\": 1646643016,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"kRNVuNuBdXnpYZPpjEk0D\",\n \"focus\": 0.30583565140977975,\n \"gap\": 15.212322625487786\n },\n \"endBinding\": {\n \"elementId\": \"obL29l9ZYGstRj4vXCE44\",\n \"focus\": 0.0039937787091913176,\n \"gap\": 19.788982664910918\n },\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 802.0454354458544,\n 2.6574234155678584\n ]\n ]\n },\n {\n \"type\": \"rectangle\",\n \"version\": 397,\n \"versionNonce\": 1152587735,\n \"isDeleted\": false,\n \"id\": \"obL29l9ZYGstRj4vXCE44\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 60,\n \"angle\": 0,\n \"x\": 1089.0285727731305,\n \"y\": -1509.4601240582274,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 581.1430909374612,\n \"height\": 138.20556938473774,\n \"seed\": 1467850312,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"tq3ElJ69jp4rnBi2WYBFQ\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"8ChRftWBO4j_Ruybyg87y\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"cWBRzb344iWZURPu1ik5n\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"NKaWwPmisMr0fbcSotNQq\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"ellipse\",\n \"version\": 284,\n \"versionNonce\": 1703687449,\n \"isDeleted\": false,\n \"id\": \"-qXhGJ1i8xBI5BHTyOj4J\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 40,\n \"angle\": 0,\n \"x\": 520.0710039086141,\n \"y\": -1580.9175569878403,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#1e1e1e\",\n \"width\": 33.74648501801634,\n \"height\": 29.77631031001452,\n \"seed\": 1390967880,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"ellipse\",\n \"version\": 302,\n \"versionNonce\": 810550519,\n \"isDeleted\": false,\n \"id\": \"ZFZMfJFx3CLxefbY7AFna\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 40,\n \"angle\": 0,\n \"x\": 517.805338836733,\n \"y\": -1159.5038536179854,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#1e1e1e\",\n \"width\": 33.74648501801634,\n \"height\": 29.77631031001452,\n \"seed\": 253495880,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 100,\n \"versionNonce\": 1079519737,\n \"isDeleted\": false,\n \"id\": \"MTP-OK3H_DzDP_K912UZ-\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 457.64596890178905,\n \"y\": -1529.7787606827383,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#1e1e1e\",\n \"width\": 176.43333435058594,\n \"height\": 61.17295694078546,\n \"seed\": 530235704,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 48.93836555262837,\n \"fontFamily\": 1,\n \"text\": \"Mapping\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Mapping\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"arrow\",\n \"version\": 609,\n \"versionNonce\": 806506007,\n \"isDeleted\": false,\n \"id\": \"itHyPYmfj5xzKP2Ow850H\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -353.25274725274653,\n \"y\": -1432.8247863247861,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#1e1e1e\",\n \"width\": 543.333333333333,\n \"height\": 170.02761443294935,\n \"seed\": 2023769656,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"IO9K5731sZw6CRw0dPcOU\",\n \"focus\": -0.3376831754128744,\n \"gap\": 17.85120770843764\n },\n \"endBinding\": {\n \"elementId\": \"njaUYnRZqAI3nJ_HU7l1D\",\n \"focus\": 0.5072278097752106,\n \"gap\": 27.50000000000034\n },\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"triangle\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -258.33333333333326,\n -107.50000000000023\n ],\n [\n -543.333333333333,\n 62.52761443294912\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 338,\n \"versionNonce\": 1267892953,\n \"isDeleted\": false,\n \"id\": \"5fdegXmuZSZSFscUd8DZb\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -912.4194139194128,\n \"y\": -1653.2124210938978,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#1e1e1e\",\n \"width\": 563.0999755859375,\n \"height\": 58.94441193829937,\n \"seed\": 797899064,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 47.15552955063949,\n \"fontFamily\": 1,\n \"text\": \"3. World State Collapse\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"3. World State Collapse\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 422,\n \"versionNonce\": 1324249911,\n \"isDeleted\": false,\n \"id\": \"njaUYnRZqAI3nJ_HU7l1D\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -2529.919413919413,\n \"y\": -1780.3247863247861,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 1605.8333333333328,\n \"height\": 879.0666666666665,\n \"seed\": 1551377464,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"itHyPYmfj5xzKP2Ow850H\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"rectangle\",\n \"version\": 235,\n \"versionNonce\": 869187513,\n \"isDeleted\": false,\n \"id\": \"afiUO8lC8sTa_RRFCKo2d\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -2464.312747252746,\n \"y\": -1721.3114529914526,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 1491.1466666666659,\n \"height\": 222.1399999999998,\n \"seed\": 986657592,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 362,\n \"versionNonce\": 1162409047,\n \"isDeleted\": false,\n \"id\": \"Oi2YfRgYx5UFrA5Y5MeSJ\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -2423.1870625196725,\n \"y\": -1649.8181196581195,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 1408.4000244140625,\n \"height\": 61.279999999999966,\n \"seed\": 1829855048,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 49.02399999999997,\n \"fontFamily\": 1,\n \"text\": \"Kec(Address), RLP(nonce, balance, storageRoot, codeHash)\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Kec(Address), RLP(nonce, balance, storageRoot, codeHash)\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 343,\n \"versionNonce\": 1194352793,\n \"isDeleted\": false,\n \"id\": \"2iUEVIQiAkqc5Bt4NVoaZ\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -2436.086080586079,\n \"y\": -1194.9681196581193,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 1461.1466666666659,\n \"height\": 217.670821917808,\n \"seed\": 510644024,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 470,\n \"versionNonce\": 1257656695,\n \"isDeleted\": false,\n \"id\": \"Uqqhd6xzPl4VrUj0xkOZW\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -2395.7877930296704,\n \"y\": -1124.91314248917,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 1380.199951171875,\n \"height\": 60.047123287671205,\n \"seed\": 1596008504,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 48.037698630136966,\n \"fontFamily\": 1,\n \"text\": \"Kec(Address), RLP(nonce, balance, storageRoot, codeHash)\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Kec(Address), RLP(nonce, balance, storageRoot, codeHash)\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"ellipse\",\n \"version\": 542,\n \"versionNonce\": 1131079033,\n \"isDeleted\": false,\n \"id\": \"5BhZvjgVP7KT_hiLmkNYw\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 40,\n \"angle\": 0,\n \"x\": -1747.8703963995326,\n \"y\": -1347.2491737420585,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#1e1e1e\",\n \"width\": 20.971784147104845,\n \"height\": 18.504515423916104,\n \"seed\": 1503422536,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"ellipse\",\n \"version\": 442,\n \"versionNonce\": 691735191,\n \"isDeleted\": false,\n \"id\": \"DDfd9b0PyC0fFF__OqPvi\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 40,\n \"angle\": 0,\n \"x\": -1745.912056339652,\n \"y\": -1283.436929887677,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#1e1e1e\",\n \"width\": 20.971784147104845,\n \"height\": 18.504515423916104,\n \"seed\": 1232609096,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"ellipse\",\n \"version\": 540,\n \"versionNonce\": 1673645657,\n \"isDeleted\": false,\n \"id\": \"K7ZvqQZMnkABhs-YTF0pB\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 40,\n \"angle\": 0,\n \"x\": -1747.8703963995326,\n \"y\": -1408.4971581858113,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#1e1e1e\",\n \"width\": 20.971784147104845,\n \"height\": 18.504515423916104,\n \"seed\": 1004317752,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"ellipse\",\n \"version\": 440,\n \"versionNonce\": 214671287,\n \"isDeleted\": false,\n \"id\": \"o-KmRwyPr78oDKxbICZpJ\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 40,\n \"angle\": 0,\n \"x\": -1745.912056339652,\n \"y\": -1344.6849143314298,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"#1e1e1e\",\n \"width\": 20.971784147104845,\n \"height\": 18.504515423916104,\n \"seed\": 1424647480,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"arrow\",\n \"version\": 149,\n \"versionNonce\": 789093177,\n \"isDeleted\": false,\n \"id\": \"d-8g6cRh6HKySNki2vzBy\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -1819.9194139194128,\n \"y\": -839.4914529914529,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 896.6666666666656,\n \"height\": 1219.9999999999993,\n \"seed\": 1071661368,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"triangle\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -56.666666666666515,\n 1089.9999999999993\n ],\n [\n 839.9999999999991,\n 1219.9999999999993\n ]\n ]\n },\n {\n \"type\": \"rectangle\",\n \"version\": 332,\n \"versionNonce\": 399282391,\n \"isDeleted\": false,\n \"id\": \"O5RdCH54twhws93e1R4jr\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -801.7843311651004,\n \"y\": 309.3186171479472,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 73.7988155422428,\n \"height\": 42.34358268817212,\n \"seed\": 769217352,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"rectangle\",\n \"version\": 460,\n \"versionNonce\": 94555161,\n \"isDeleted\": false,\n \"id\": \"gCIXqbAchJOzEEvzvs-BE\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -566.1535262695547,\n \"y\": 306.29407552736336,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 68.95954894930885,\n \"height\": 39.923949391705115,\n \"seed\": 2095032904,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"rectangle\",\n \"version\": 457,\n \"versionNonce\": 869424631,\n \"isDeleted\": false,\n \"id\": \"5zj9Kr5YdLGd8CLEWpbzH\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -733.1272363778498,\n \"y\": 452.3794358015574,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 68.95954894930885,\n \"height\": 39.923949391705115,\n \"seed\": 1728258376,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"rectangle\",\n \"version\": 391,\n \"versionNonce\": 1870913785,\n \"isDeleted\": false,\n \"id\": \"U4A_ePSYRBAVMLr4QPY3H\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -630.8977296021201,\n \"y\": 449.3548941809736,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 73.7988155422428,\n \"height\": 42.34358268817212,\n \"seed\": 1268758600,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"rectangle\",\n \"version\": 531,\n \"versionNonce\": 601982743,\n \"isDeleted\": false,\n \"id\": \"uHkvOmRBPcFIpqaNIMyEw\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -506.8915231581872,\n \"y\": 454.79906909802446,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 68.95954894930885,\n \"height\": 39.923949391705115,\n \"seed\": 1049718600,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"line\",\n \"version\": 339,\n \"versionNonce\": 707746265,\n \"isDeleted\": false,\n \"id\": \"w5gG6AwzDeakHjIESXXOA\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -798.1548812203998,\n \"y\": 344.4032999467187,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 82.26753207987724,\n \"height\": 102.8344150998465,\n \"seed\": 2016691784,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -82.26753207987724,\n 102.8344150998465\n ]\n ]\n },\n {\n \"type\": \"line\",\n \"version\": 335,\n \"versionNonce\": 1450085431,\n \"isDeleted\": false,\n \"id\": \"-hZv-dA09w40EwyWHFWBa\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -734.0345988640252,\n \"y\": 348.0327498914187,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 31.45523285407074,\n \"height\": 95.57551521044567,\n \"seed\": 1164197192,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 31.45523285407074,\n 95.57551521044567\n ]\n ]\n },\n {\n \"type\": \"line\",\n \"version\": 289,\n \"versionNonce\": 1991816889,\n \"isDeleted\": false,\n \"id\": \"UtFxXracS0jcrqd_JsZtx\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -551.3522849807682,\n \"y\": 340.7738500020181,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 53.2319325222735,\n \"height\": 108.88349834101392,\n \"seed\": 2004702280,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -53.2319325222735,\n 108.88349834101392\n ]\n ]\n },\n {\n \"type\": \"line\",\n \"version\": 329,\n \"versionNonce\": 2002644311,\n \"isDeleted\": false,\n \"id\": \"H1VH1uJYWR60mTipcwNkl\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -525.946135367865,\n \"y\": 343.1934832984849,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 49.60248257757304,\n \"height\": 107.6736816927805,\n \"seed\": 1415285576,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 49.60248257757304,\n 107.6736816927805\n ]\n ]\n },\n {\n \"type\": \"line\",\n \"version\": 302,\n \"versionNonce\": 667121561,\n \"isDeleted\": false,\n \"id\": \"AzdK11AGgvUwi2RNBfsda\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -724.3560656781572,\n \"y\": 328.67568351968305,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 152.4368976774197,\n \"height\": 1.2098166482334067,\n \"seed\": 106619464,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 152.4368976774197,\n -1.2098166482334067\n ]\n ]\n },\n {\n \"type\": \"rectangle\",\n \"version\": 361,\n \"versionNonce\": 1107569271,\n \"isDeleted\": false,\n \"id\": \"9SPY4jBtshWRrcUrHOSHK\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -920.1521550238677,\n \"y\": 429.3367556644604,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 83.7988155422428,\n \"height\": 59.01024935483863,\n \"seed\": 2004622664,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 218,\n \"versionNonce\": 1870863481,\n \"isDeleted\": false,\n \"id\": \"S7RJ8Stuo3Al34DgSYFkm\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -1816.5860805860793,\n \"y\": 125.50854700854643,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 1220.7332763671875,\n \"height\": 81.666666666667,\n \"seed\": 1881286472,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 65.3333333333336,\n \"fontFamily\": 1,\n \"text\": \"4. Transform To Trie Datastructure\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"4. Transform To Trie Datastructure\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"arrow\",\n \"version\": 443,\n \"versionNonce\": 321242007,\n \"isDeleted\": false,\n \"id\": \"A7nC1xZKEEOhIKoBirhse\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 60,\n \"angle\": 0,\n \"x\": -321.84031845355,\n \"y\": 451.46558195900116,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 925,\n \"height\": 58.333333333333485,\n \"seed\": 974154040,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 485.00000000000045,\n -24.999999999999773\n ],\n [\n 925,\n -58.333333333333485\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 507,\n \"versionNonce\": 1840981337,\n \"isDeleted\": false,\n \"id\": \"PTIrdAmJefEjibs2KGmiH\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 6.196735235821938,\n \"x\": -320.17300226471633,\n \"y\": 262.1837100294972,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 878.6500244140625,\n \"height\": 82.34525423052457,\n \"seed\": 1507850040,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 65.87620338441965,\n \"fontFamily\": 1,\n \"text\": \"5. Collapse into Root Node\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"5. Collapse into Root Node\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 567,\n \"versionNonce\": 989280439,\n \"isDeleted\": false,\n \"id\": \"664rrH-vD4HrIUEfDy0SX\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dotted\",\n \"roughness\": 2,\n \"opacity\": 80,\n \"angle\": 0,\n \"x\": 906.0979147893286,\n \"y\": 366.0242071352584,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 131.52462701818916,\n \"height\": 75.46494992846922,\n \"seed\": 2072747832,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"9pqFdJiYK9S_Rzao-I5P2\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"rectangle\",\n \"version\": 675,\n \"versionNonce\": 2109674041,\n \"isDeleted\": false,\n \"id\": \"Y5c7TrX1s4V8wl58iI1-u\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dotted\",\n \"roughness\": 2,\n \"opacity\": 80,\n \"angle\": 0,\n \"x\": 1308.2182908367433,\n \"y\": 360.63385356893934,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 122.90006131207839,\n \"height\": 71.15266707541379,\n \"seed\": 1212348472,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"w5ZWrmtECuQb6tADcF2qt\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"rectangle\",\n \"version\": 628,\n \"versionNonce\": 1562726457,\n \"isDeleted\": false,\n \"id\": \"v-8f7cdTSdbM5hKQxY0ds\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dotted\",\n \"roughness\": 2,\n \"opacity\": 80,\n \"angle\": 0,\n \"x\": 778.5509088624946,\n \"y\": 554.6431525675088,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 131.52462701818916,\n \"height\": 75.46494992846922,\n \"seed\": 380055864,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"RPeI035oI7kFQTpVC5ZDo\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710062968160,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"rectangle\",\n \"version\": 713,\n \"versionNonce\": 791245497,\n \"isDeleted\": false,\n \"id\": \"edOWKZ1ItMihsg1JIZvGX\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dotted\",\n \"roughness\": 2,\n \"opacity\": 80,\n \"angle\": 0,\n \"x\": 1020.602819755607,\n \"y\": 544.1475465997999,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 122.90006131207839,\n \"height\": 71.15266707541379,\n \"seed\": 1578912312,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"mQSgzSa6WMA4CvO8MC9xZ\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710062952937,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"rectangle\",\n \"version\": 634,\n \"versionNonce\": 1561354425,\n \"isDeleted\": false,\n \"id\": \"_zw9cD4pgFZai0tMWApL5\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dotted\",\n \"roughness\": 2,\n \"opacity\": 80,\n \"angle\": 0,\n \"x\": 1224.4634369638636,\n \"y\": 550.4238597001475,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 131.52462701818916,\n \"height\": 75.46494992846922,\n \"seed\": 159793976,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"HKLsnMZUT6zOTPH89D3lL\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710062955637,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"line\",\n \"version\": 532,\n \"versionNonce\": 2118686713,\n \"isDeleted\": false,\n \"id\": \"EYBO0OAdDJ9FKfskuTuZG\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dotted\",\n \"roughness\": 2,\n \"opacity\": 80,\n \"angle\": 0,\n \"x\": 1044.0909660871005,\n \"y\": 400.5224699597019,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 271.6738197424893,\n \"height\": 2.156141426527545,\n \"seed\": 122231864,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 271.6738197424893,\n -2.156141426527545\n ]\n ]\n },\n {\n \"type\": \"rectangle\",\n \"version\": 558,\n \"versionNonce\": 1512554519,\n \"isDeleted\": false,\n \"id\": \"Zh_F-8ivDUcZR13YVyYIe\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 963.1120165673785,\n \"y\": 50.71688034188037,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 385.60188023707326,\n \"height\": 223.66666666666663,\n \"seed\": 1497945400,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"7wlD71WLCsHvHcWKmaWuv\"\n },\n {\n \"id\": \"9pqFdJiYK9S_Rzao-I5P2\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 624,\n \"versionNonce\": 222638297,\n \"isDeleted\": false,\n \"id\": \"7wlD71WLCsHvHcWKmaWuv\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 981.2379536341573,\n \"y\": 60.67253127178023,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 349.3500061035156,\n \"height\": 203.7553648068669,\n \"seed\": 619277880,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710062878125,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 54.334763948497844,\n \"fontFamily\": 1,\n \"text\": \"Root: Parent\\nBlock World \\nState ID\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"Zh_F-8ivDUcZR13YVyYIe\",\n \"originalText\": \"Root: Parent Block World State ID\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"arrow\",\n \"version\": 932,\n \"versionNonce\": 196564473,\n \"isDeleted\": false,\n \"id\": \"RPeI035oI7kFQTpVC5ZDo\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 2,\n \"opacity\": 80,\n \"angle\": 0,\n \"x\": 837.0920423721611,\n \"y\": 543.0538923999222,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 122.9094080803595,\n \"height\": 102.91232372777404,\n \"seed\": 1125050168,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062968260,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"v-8f7cdTSdbM5hKQxY0ds\",\n \"focus\": -0.5966679453351551,\n \"gap\": 11.58926016758653\n },\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 122.9094080803595,\n -102.91232372777404\n ]\n ]\n },\n {\n \"type\": \"arrow\",\n \"version\": 1071,\n \"versionNonce\": 1896322521,\n \"isDeleted\": false,\n \"id\": \"mQSgzSa6WMA4CvO8MC9xZ\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 2,\n \"opacity\": 80,\n \"angle\": 0,\n \"x\": 1052.451396467568,\n \"y\": 530.6995085863109,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 77.11348890326438,\n \"height\": 99.02079501328465,\n \"seed\": 1344094264,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062952937,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"edOWKZ1ItMihsg1JIZvGX\",\n \"focus\": 0.09620040263855374,\n \"gap\": 13.44803801348894\n },\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -77.11348890326438,\n -99.02079501328465\n ]\n ]\n },\n {\n \"type\": \"arrow\",\n \"version\": 942,\n \"versionNonce\": 1713271863,\n \"isDeleted\": false,\n \"id\": \"HKLsnMZUT6zOTPH89D3lL\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 2,\n \"opacity\": 80,\n \"angle\": 0,\n \"x\": 1286.9517731827461,\n \"y\": 538.3451247726995,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 76.24812403045244,\n \"height\": 113.29654608624514,\n \"seed\": 1006139704,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062959439,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"_zw9cD4pgFZai0tMWApL5\",\n \"focus\": -0.40366706630298405,\n \"gap\": 12.078734927448068\n },\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 76.24812403045244,\n -113.29654608624514\n ]\n ]\n },\n {\n \"type\": \"arrow\",\n \"version\": 1043,\n \"versionNonce\": 42962585,\n \"isDeleted\": false,\n \"id\": \"9pqFdJiYK9S_Rzao-I5P2\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 992.5044560696338,\n \"y\": 360.07310351784594,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 127.05145994593613,\n \"height\": 81.64214183527491,\n \"seed\": 1510249016,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"664rrH-vD4HrIUEfDy0SX\",\n \"focus\": -0.3802662066171751,\n \"gap\": 5.951103617412457\n },\n \"endBinding\": {\n \"elementId\": \"Zh_F-8ivDUcZR13YVyYIe\",\n \"focus\": -0.39248207234147364,\n \"gap\": 4.047414674024026\n },\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 127.05145994593613,\n -81.64214183527491\n ]\n ]\n },\n {\n \"type\": \"arrow\",\n \"version\": 932,\n \"versionNonce\": 1525220215,\n \"isDeleted\": false,\n \"id\": \"w5ZWrmtECuQb6tADcF2qt\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1343.4078419126306,\n \"y\": 353.8959116110402,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 131.13784455637045,\n \"height\": 79.77723278152466,\n \"seed\": 1898285880,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"Y5c7TrX1s4V8wl58iI1-u\",\n \"focus\": 0.3610071718116547,\n \"gap\": 6.737941957899125\n },\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -131.13784455637045,\n -79.77723278152466\n ]\n ]\n },\n {\n \"type\": \"rectangle\",\n \"version\": 828,\n \"versionNonce\": 231083001,\n \"isDeleted\": false,\n \"id\": \"ZIdCp8uOvXumP5tGbJX1m\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dotted\",\n \"roughness\": 2,\n \"opacity\": 80,\n \"angle\": 0,\n \"x\": 1475.1962259301404,\n \"y\": 551.6816257860721,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 122.90006131207839,\n \"height\": 71.15266707541379,\n \"seed\": 139028552,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"91vFNWcr_SEo8lhf2QYhI\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710062963474,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"arrow\",\n \"version\": 1017,\n \"versionNonce\": 888415449,\n \"isDeleted\": false,\n \"id\": \"91vFNWcr_SEo8lhf2QYhI\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 2,\n \"opacity\": 80,\n \"angle\": 0,\n \"x\": 1512.8912352779892,\n \"y\": 546.8952813484406,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 106.7969933394725,\n \"height\": 127.0263641937472,\n \"seed\": 444931912,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062963474,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"ZIdCp8uOvXumP5tGbJX1m\",\n \"focus\": 0.11142388738137558,\n \"gap\": 4.786344437631556\n },\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -106.7969933394725,\n -127.0263641937472\n ]\n ]\n },\n {\n \"type\": \"rectangle\",\n \"version\": 478,\n \"versionNonce\": 2007858265,\n \"isDeleted\": false,\n \"id\": \"7fkM77fMyZdFPuL-GGdGn\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dotted\",\n \"roughness\": 2,\n \"opacity\": 30,\n \"angle\": 0,\n \"x\": 1163.9050595605252,\n \"y\": -1610.897661917048,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 118.46191661548927,\n \"height\": 67.96995215642829,\n \"seed\": 1206760008,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"ThWwj5oekaG3XGBGIYGEp\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"rectangle\",\n \"version\": 585,\n \"versionNonce\": 1094308279,\n \"isDeleted\": false,\n \"id\": \"Z0Jk3AljsK4MDKNqKvZWt\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dotted\",\n \"roughness\": 2,\n \"opacity\": 30,\n \"angle\": 0,\n \"x\": 1526.0878046226358,\n \"y\": -1615.7526584996497,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 110.69392208332602,\n \"height\": 64.08595489034663,\n \"seed\": 856697160,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"CCgx6ihS_E1C5kETipSEw\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"rectangle\",\n \"version\": 525,\n \"versionNonce\": 1699645753,\n \"isDeleted\": false,\n \"id\": \"Qeb2sjsn4AFl9PeU0NezG\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dotted\",\n \"roughness\": 2,\n \"opacity\": 30,\n \"angle\": 0,\n \"x\": 1026.508656272888,\n \"y\": -1456.023270932043,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 118.46191661548927,\n \"height\": 67.96995215642829,\n \"seed\": 550223944,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"8ChRftWBO4j_Ruybyg87y\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"rectangle\",\n \"version\": 605,\n \"versionNonce\": 1134854871,\n \"isDeleted\": false,\n \"id\": \"gq7LlfxCFuYgrJ0AkW03E\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dotted\",\n \"roughness\": 2,\n \"opacity\": 30,\n \"angle\": 0,\n \"x\": 1309.0694573803262,\n \"y\": -1441.4582811842372,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 110.69392208332602,\n \"height\": 64.08595489034663,\n \"seed\": 553416520,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"cWBRzb344iWZURPu1ik5n\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"rectangle\",\n \"version\": 538,\n \"versionNonce\": 419101209,\n \"isDeleted\": false,\n \"id\": \"CWEnpiJTOAPW2rES27NWO\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dotted\",\n \"roughness\": 2,\n \"opacity\": 30,\n \"angle\": 0,\n \"x\": 1473.168341872275,\n \"y\": -1446.3132777668388,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 118.46191661548927,\n \"height\": 67.96995215642829,\n \"seed\": 1744719432,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"nGPWXq3ALcaug1tLTW1jL\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"rectangle\",\n \"version\": 682,\n \"versionNonce\": 1138495479,\n \"isDeleted\": false,\n \"id\": \"kn3yzoFJIRvExBh9ZTSI_\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dotted\",\n \"roughness\": 2,\n \"opacity\": 30,\n \"angle\": 0,\n \"x\": 1654.0978811839095,\n \"y\": -1440.9727815259764,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 110.69392208332602,\n \"height\": 64.08595489034663,\n \"seed\": 1051542856,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [],\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"line\",\n \"version\": 443,\n \"versionNonce\": 61230841,\n \"isDeleted\": false,\n \"id\": \"Oy-pdPnxFs7jvLuFxSe1V\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dotted\",\n \"roughness\": 2,\n \"opacity\": 30,\n \"angle\": 0,\n \"x\": 1288.192972075137,\n \"y\": -1579.8256837883944,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 244.6918277631419,\n \"height\": 1.9419986330406758,\n \"seed\": 1919245384,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 244.6918277631419,\n -1.9419986330406758\n ]\n ]\n },\n {\n \"type\": \"rectangle\",\n \"version\": 372,\n \"versionNonce\": 736426263,\n \"isDeleted\": false,\n \"id\": \"zD_M8iRxwNoOe1E4-SRaO\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 30,\n \"angle\": 0,\n \"x\": 1284.308974809055,\n \"y\": -1773.2972976050853,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 227.21384006577446,\n \"height\": 85.44793985379593,\n \"seed\": 1157796680,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"x8BmngmY79eNJoK2JTJnm\"\n }\n ],\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 507,\n \"versionNonce\": 735315929,\n \"isDeleted\": false,\n \"id\": \"x8BmngmY79eNJoK2JTJnm\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 30,\n \"angle\": 0,\n \"x\": 1340.3825620172352,\n \"y\": -1761.1598061485802,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 115.06666564941406,\n \"height\": 61.17295694078546,\n \"seed\": 1558243912,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 48.93836555262837,\n \"fontFamily\": 1,\n \"text\": \"Root\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"zD_M8iRxwNoOe1E4-SRaO\",\n \"originalText\": \"Root\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"arrow\",\n \"version\": 1037,\n \"versionNonce\": 825474615,\n \"isDeleted\": false,\n \"id\": \"8ChRftWBO4j_Ruybyg87y\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 2,\n \"opacity\": 30,\n \"angle\": 0,\n \"x\": 1083.5803253553456,\n \"y\": -1466.4615135846377,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 2.0451065676867555,\n \"height\": 0.15685347299973423,\n \"seed\": 886858056,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"Qeb2sjsn4AFl9PeU0NezG\",\n \"focus\": 1.1487184621643522,\n \"gap\": 10.438242652594568\n },\n \"endBinding\": {\n \"elementId\": \"obL29l9ZYGstRj4vXCE44\",\n \"gap\": 5.512254862432314,\n \"focus\": 0.03720757708157418\n },\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -2.0451065676867555,\n -0.15685347299973423\n ]\n ]\n },\n {\n \"type\": \"arrow\",\n \"version\": 1345,\n \"versionNonce\": 2073535673,\n \"isDeleted\": false,\n \"id\": \"cWBRzb344iWZURPu1ik5n\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 2,\n \"opacity\": 30,\n \"angle\": 0,\n \"x\": 1287.9502222460073,\n \"y\": -1396.1265386195844,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 214.03734809303373,\n \"height\": 5.871759417914036,\n \"seed\": 206633032,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"VvqpZglNwpgM3Yhfdwxd2\",\n \"focus\": -0.8312183133482495,\n \"gap\": 1.2295146715341616\n },\n \"endBinding\": {\n \"elementId\": \"obL29l9ZYGstRj4vXCE44\",\n \"focus\": 0.5412521223836315,\n \"gap\": 15.115698620156763\n },\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -214.03734809303373,\n 5.871759417914036\n ]\n ]\n },\n {\n \"type\": \"arrow\",\n \"version\": 777,\n \"versionNonce\": 1722605399,\n \"isDeleted\": false,\n \"id\": \"nGPWXq3ALcaug1tLTW1jL\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 2,\n \"opacity\": 30,\n \"angle\": 0,\n \"x\": 1499.0556750742194,\n \"y\": -1458.6935190524748,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 76.55309469095747,\n \"height\": 99.04193028508064,\n \"seed\": 1461366600,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"CWEnpiJTOAPW2rES27NWO\",\n \"focus\": -0.8091420651756349,\n \"gap\": 12.380241285635861\n },\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 76.55309469095747,\n -99.04193028508064\n ]\n ]\n },\n {\n \"type\": \"arrow\",\n \"version\": 827,\n \"versionNonce\": 1318364569,\n \"isDeleted\": false,\n \"id\": \"NKaWwPmisMr0fbcSotNQq\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 2,\n \"opacity\": 30,\n \"angle\": 0,\n \"x\": 1680.8167207772126,\n \"y\": -1470.831010508979,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 88.79027143692994,\n \"height\": 87.3899384868369,\n \"seed\": 764773960,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"obL29l9ZYGstRj4vXCE44\",\n \"focus\": 0.9207192232962585,\n \"gap\": 10.645057066620893\n },\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -88.79027143692994,\n -87.3899384868369\n ]\n ]\n },\n {\n \"type\": \"arrow\",\n \"version\": 764,\n \"versionNonce\": 245685367,\n \"isDeleted\": false,\n \"id\": \"ThWwj5oekaG3XGBGIYGEp\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 30,\n \"angle\": 0,\n \"x\": 1249.2355971266245,\n \"y\": -1623.763402860943,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 106.92732710494082,\n \"height\": 66.02795352338761,\n \"seed\": 1016954184,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"7fkM77fMyZdFPuL-GGdGn\",\n \"focus\": -0.43557294063505786,\n \"gap\": 12.86574094389482\n },\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 106.92732710494082,\n -66.02795352338761\n ]\n ]\n },\n {\n \"type\": \"arrow\",\n \"version\": 794,\n \"versionNonce\": 1073646201,\n \"isDeleted\": false,\n \"id\": \"CCgx6ihS_E1C5kETipSEw\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 30,\n \"angle\": 0,\n \"x\": 1557.7824139121335,\n \"y\": -1621.8214042279023,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 118.11354845981325,\n \"height\": 71.85394942250996,\n \"seed\": 898536520,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"Z0Jk3AljsK4MDKNqKvZWt\",\n \"focus\": 0.3610071718116692,\n \"gap\": 6.068745728252793\n },\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -118.11354845981325,\n -71.85394942250996\n ]\n ]\n },\n {\n \"type\": \"rectangle\",\n \"version\": 188,\n \"versionNonce\": 752891287,\n \"isDeleted\": false,\n \"id\": \"ySzAkDdXf6y0y5vZ0ERtM\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 80,\n \"angle\": 0,\n \"x\": -2688.2527472527463,\n \"y\": -2450.3247863247857,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 6296.666666666663,\n \"height\": 3273.333333333331,\n \"seed\": 906089784,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [],\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 195,\n \"versionNonce\": 949539673,\n \"isDeleted\": false,\n \"id\": \"-S3v0jMacMhCwTzq1iUkr\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -2496.0082811069187,\n \"y\": -2345.324786324786,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 1149.933349609375,\n \"height\": 210.00000000000043,\n \"seed\": 1851288904,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 84.00000000000017,\n \"fontFamily\": 1,\n \"text\": \" STATE OBSERVATIONS \\n(Yellow Paper's Perspective)\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \" STATE OBSERVATIONS \\n(Yellow Paper's Perspective)\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 199,\n \"versionNonce\": 1486056119,\n \"isDeleted\": false,\n \"id\": \"yxabqq0rH84BfUbZ3cQUa\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -656.5860805860807,\n \"y\": -385.3247863247875,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 650,\n \"height\": 389.9999999999998,\n \"seed\": 1103448570,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"EzQPD-S0Z_kNojS1czb8O\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"pko9jThYHExG3FyK8LVDp\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 155,\n \"versionNonce\": 1018626105,\n \"isDeleted\": false,\n \"id\": \"pBaVZumKtgHiRk9CusL3S\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -513.2527472527477,\n \"y\": -355.3247863247875,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 371.3666687011719,\n \"height\": 56.70682001050052,\n \"seed\": 967541862,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 45.365456008400415,\n \"fontFamily\": 1,\n \"text\": \"Account Storage\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Account Storage\",\n \"lineHeight\": 1.25\n },\n {\n \"id\": \"nqnoDMJkAZ-wv6_n4DWK8\",\n \"type\": \"ellipse\",\n \"x\": 2562.8843338883075,\n \"y\": -1056.8031288942261,\n \"width\": 529.9999999999999,\n \"height\": 393.33333333333354,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"seed\": 23948471,\n \"version\": 294,\n \"versionNonce\": 2050789657,\n \"isDeleted\": false,\n \"boundElements\": [\n {\n \"id\": \"e4yLYg3nJ68_4SF7UBn4q\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"kay9auKBKy7_8byISiJVO\",\n \"type\": \"arrow\"\n },\n {\n \"id\": \"jE4UVwVXKRGqT1MPrvFBw\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false\n },\n {\n \"id\": \"e4yLYg3nJ68_4SF7UBn4q\",\n \"type\": \"arrow\",\n \"x\": 2312.8843338883084,\n \"y\": -1423.469795560892,\n \"width\": 563.039740983229,\n \"height\": 462.9294616180214,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"seed\": 821771065,\n \"version\": 413,\n \"versionNonce\": 1113811191,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 420,\n -100\n ],\n [\n 563.039740983229,\n 362.9294616180214\n ]\n ],\n \"lastCommittedPoint\": null,\n \"startBinding\": null,\n \"endBinding\": {\n \"elementId\": \"nqnoDMJkAZ-wv6_n4DWK8\",\n \"focus\": 0.4044539277264122,\n \"gap\": 6.932449870536459\n },\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\"\n },\n {\n \"id\": \"4co8J3ySyOBwHZAM70frw\",\n \"type\": \"text\",\n \"x\": 2676.2176672216433,\n \"y\": -970.1364622275592,\n \"width\": 369.6000061035156,\n \"height\": 208.33333333333346,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"seed\": 994390553,\n \"version\": 214,\n \"versionNonce\": 1914253847,\n \"isDeleted\": false,\n \"boundElements\": [\n {\n \"id\": \"jE4UVwVXKRGqT1MPrvFBw\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false,\n \"text\": \"STATE\\nTRANSITION\\nFUNCTION\",\n \"fontSize\": 55.55555555555559,\n \"fontFamily\": 1,\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"STATE\\nTRANSITION\\nFUNCTION\",\n \"lineHeight\": 1.25\n },\n {\n \"id\": \"k_i_EVf3OyMy8xRyUtvWH\",\n \"type\": \"rectangle\",\n \"x\": 2916.2176672216424,\n \"y\": -1940.1364622275585,\n \"width\": 480,\n \"height\": 146.66666666666652,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"seed\": 351891127,\n \"version\": 267,\n \"versionNonce\": 1021042393,\n \"isDeleted\": false,\n \"boundElements\": [],\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false\n },\n {\n \"id\": \"CsJS7XJCk8HukqKTe_faa\",\n \"type\": \"text\",\n \"x\": 2976.2176672216433,\n \"y\": -1906.803128894225,\n \"width\": 374.73333740234375,\n \"height\": 72.86979679525871,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"seed\": 520201015,\n \"version\": 306,\n \"versionNonce\": 1987630903,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false,\n \"text\": \"Transactions\",\n \"fontSize\": 58.295837436206966,\n \"fontFamily\": 1,\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Transactions\",\n \"lineHeight\": 1.25\n },\n {\n \"id\": \"jE4UVwVXKRGqT1MPrvFBw\",\n \"type\": \"arrow\",\n \"x\": 3107.5452945979278,\n \"y\": -1703.4697955608935,\n \"width\": 221.32762737628536,\n \"height\": 646.6666666666677,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"seed\": 373220695,\n \"version\": 586,\n \"versionNonce\": 1804377017,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -161.32762737628627,\n 313.3333333333346\n ],\n [\n -221.32762737628536,\n 646.6666666666677\n ]\n ],\n \"lastCommittedPoint\": null,\n \"startBinding\": {\n \"elementId\": \"MQ1JS_Ai8PRa2Z3H4qt5f\",\n \"focus\": -0.13453826005696246,\n \"gap\": 23.583333333331097\n },\n \"endBinding\": {\n \"elementId\": \"nqnoDMJkAZ-wv6_n4DWK8\",\n \"focus\": 0.08577890566234538,\n \"gap\": 4.758587918219746\n },\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\"\n },\n {\n \"id\": \"Mt5mBrbriTqEQfWIFYi8b\",\n \"type\": \"rectangle\",\n \"x\": 2519.5510005549736,\n \"y\": -516.8031288942254,\n \"width\": 653.333333333333,\n \"height\": 213.33333333333348,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"seed\": 634720697,\n \"version\": 166,\n \"versionNonce\": 1441192023,\n \"isDeleted\": false,\n \"boundElements\": [\n {\n \"id\": \"kay9auKBKy7_8byISiJVO\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false\n },\n {\n \"id\": \"Hak2YGKbN4LmC0Vh6JniZ\",\n \"type\": \"text\",\n \"x\": 2636.2176672216415,\n \"y\": -443.4697955608922,\n \"width\": 414.1000061035156,\n \"height\": 78.33333333333351,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"seed\": 145337815,\n \"version\": 160,\n \"versionNonce\": 47365273,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false,\n \"text\": \"World STATE\",\n \"fontSize\": 62.666666666666806,\n \"fontFamily\": 1,\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"World STATE\",\n \"lineHeight\": 1.25\n },\n {\n \"id\": \"kay9auKBKy7_8byISiJVO\",\n \"type\": \"arrow\",\n \"x\": 2829.6155169984086,\n \"y\": -662.4739818650727,\n \"width\": 1.7720232194933487,\n \"height\": 122.33751963751354,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"seed\": 1448607671,\n \"version\": 204,\n \"versionNonce\": 1446491511,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 1.7720232194933487,\n 122.33751963751354\n ]\n ],\n \"lastCommittedPoint\": null,\n \"startBinding\": {\n \"elementId\": \"nqnoDMJkAZ-wv6_n4DWK8\",\n \"focus\": 0.0042710745638722715,\n \"gap\": 1\n },\n \"endBinding\": {\n \"elementId\": \"Mt5mBrbriTqEQfWIFYi8b\",\n \"focus\": -0.03944745086869617,\n \"gap\": 23.333333333333712\n },\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\"\n },\n {\n \"id\": \"DOx5U71tBJaDw5hW0bN7T\",\n \"type\": \"arrow\",\n \"x\": 2842.8843338883084,\n \"y\": -236.80312889422567,\n \"width\": 16.66666666666697,\n \"height\": 363.33333333333303,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"seed\": 492101751,\n \"version\": 104,\n \"versionNonce\": 308396409,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -16.66666666666697,\n 363.33333333333303\n ]\n ],\n \"lastCommittedPoint\": null,\n \"startBinding\": null,\n \"endBinding\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\"\n },\n {\n \"id\": \"2R7WzanMkUVdNlr9R_S7f\",\n \"type\": \"text\",\n \"x\": 1891.0448247013842,\n \"y\": -143.46979556089286,\n \"width\": 870.8666381835938,\n \"height\": 78.33333333333348,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"seed\": 930140951,\n \"version\": 167,\n \"versionNonce\": 246410903,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false,\n \"text\": \"6. Collapse , Get Trie Root\",\n \"fontSize\": 62.666666666666785,\n \"fontFamily\": 1,\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"6. Collapse , Get Trie Root\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"rectangle\",\n \"version\": 629,\n \"versionNonce\": 1736256089,\n \"isDeleted\": false,\n \"id\": \"ab6rp57hjTIAFyuA5YDX3\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dotted\",\n \"roughness\": 2,\n \"opacity\": 80,\n \"angle\": 0,\n \"x\": 2579.825317291947,\n \"y\": 497.8791978991518,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 131.52462701818916,\n \"height\": 75.46494992846922,\n \"seed\": 31502903,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"UCVmNFdq-CdPDouv9S5cH\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"rectangle\",\n \"version\": 737,\n \"versionNonce\": 973341623,\n \"isDeleted\": false,\n \"id\": \"oBiKdnd5XAQbDcmua_vGo\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dotted\",\n \"roughness\": 2,\n \"opacity\": 80,\n \"angle\": 0,\n \"x\": 2981.9456933393617,\n \"y\": 492.48884433283274,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 122.90006131207839,\n \"height\": 71.15266707541379,\n \"seed\": 2107331415,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"uL_8YGqxLi1BSSu7iorS0\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"rectangle\",\n \"version\": 676,\n \"versionNonce\": 1526232889,\n \"isDeleted\": false,\n \"id\": \"1R-OzlC-ndXSz2c6mC-mF\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dotted\",\n \"roughness\": 2,\n \"opacity\": 80,\n \"angle\": 0,\n \"x\": 2427.278311365113,\n \"y\": 669.8314766647354,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 131.52462701818916,\n \"height\": 75.46494992846922,\n \"seed\": 665112695,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"J5BmWYB3hNYhAOlh30C7q\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"rectangle\",\n \"version\": 756,\n \"versionNonce\": 1213756631,\n \"isDeleted\": false,\n \"id\": \"c_EM-xA0vGa03m0KKXl-u\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dotted\",\n \"roughness\": 2,\n \"opacity\": 80,\n \"angle\": 0,\n \"x\": 2740.996888924892,\n \"y\": 686.0025373636932,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 122.90006131207839,\n \"height\": 71.15266707541379,\n \"seed\": 163686807,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [],\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"rectangle\",\n \"version\": 689,\n \"versionNonce\": 1597450265,\n \"isDeleted\": false,\n \"id\": \"Qbb_-4VCiUkKAtmzjVZ0d\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dotted\",\n \"roughness\": 2,\n \"opacity\": 80,\n \"angle\": 0,\n \"x\": 2923.190839466482,\n \"y\": 680.6121837973742,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 131.52462701818916,\n \"height\": 75.46494992846922,\n \"seed\": 19291831,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"4w7PXBHM7TWlwFqChWSay\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"line\",\n \"version\": 594,\n \"versionNonce\": 826393079,\n \"isDeleted\": false,\n \"id\": \"1UiA4j8hV3sGRHA2tgVDh\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dotted\",\n \"roughness\": 2,\n \"opacity\": 80,\n \"angle\": 0,\n \"x\": 2717.818368589719,\n \"y\": 532.3774607235953,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 271.6738197424893,\n \"height\": 2.156141426527545,\n \"seed\": 1350004695,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 271.6738197424893,\n -2.156141426527545\n ]\n ]\n },\n {\n \"type\": \"rectangle\",\n \"version\": 622,\n \"versionNonce\": 1311554809,\n \"isDeleted\": false,\n \"id\": \"NU2JREi3xUp2weJX7bAJm\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 2636.839419069997,\n \"y\": 182.57187110577377,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 385.60188023707326,\n \"height\": 223.66666666666663,\n \"seed\": 1909021943,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"jWtvwGohldeGK3rhGnlo6\"\n },\n {\n \"id\": \"UCVmNFdq-CdPDouv9S5cH\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 702,\n \"versionNonce\": 96758551,\n \"isDeleted\": false,\n \"id\": \"jWtvwGohldeGK3rhGnlo6\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 2662.4320309414634,\n \"y\": 226.48674950348476,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 334.4166564941406,\n \"height\": 135.83690987124461,\n \"seed\": 681616919,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 54.334763948497844,\n \"fontFamily\": 1,\n \"text\": \"Root: World \\nState ID\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"NU2JREi3xUp2weJX7bAJm\",\n \"originalText\": \"Root: World State ID\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"arrow\",\n \"version\": 1046,\n \"versionNonce\": 2002564569,\n \"isDeleted\": false,\n \"id\": \"J5BmWYB3hNYhAOlh30C7q\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 2,\n \"opacity\": 80,\n \"angle\": 0,\n \"x\": 2496.4676430256745,\n \"y\": 658.2422164971489,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 137.2612099294648,\n \"height\": 86.2456570611073,\n \"seed\": 1408355127,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"1R-OzlC-ndXSz2c6mC-mF\",\n \"focus\": -0.5966679453351519,\n \"gap\": 11.58926016758653\n },\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 137.2612099294648,\n -86.2456570611073\n ]\n ]\n },\n {\n \"type\": \"arrow\",\n \"version\": 1132,\n \"versionNonce\": 1112862775,\n \"isDeleted\": false,\n \"id\": \"TN0uZVB9Gba4berRHYg-B\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 2,\n \"opacity\": 80,\n \"angle\": 0,\n \"x\": 2726.1787989701866,\n \"y\": 662.5544993502043,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 77.11348890326438,\n \"height\": 99.02079501328465,\n \"seed\": 2182231,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -77.11348890326438,\n -99.02079501328465\n ]\n ]\n },\n {\n \"type\": \"arrow\",\n \"version\": 1049,\n \"versionNonce\": 1843040953,\n \"isDeleted\": false,\n \"id\": \"4w7PXBHM7TWlwFqChWSay\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 2,\n \"opacity\": 80,\n \"angle\": 0,\n \"x\": 2951.932750294524,\n \"y\": 666.8667822032594,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 84.99454942129306,\n \"height\": 109.96321275291166,\n \"seed\": 956541303,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"Qbb_-4VCiUkKAtmzjVZ0d\",\n \"focus\": -0.8091420651756356,\n \"gap\": 13.74540159411481\n },\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 84.99454942129306,\n -109.96321275291166\n ]\n ]\n },\n {\n \"type\": \"arrow\",\n \"version\": 1239,\n \"versionNonce\": 1624756567,\n \"isDeleted\": false,\n \"id\": \"UCVmNFdq-CdPDouv9S5cH\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 2666.2318585722523,\n \"y\": 491.92809428173933,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 127.05145994593613,\n \"height\": 81.64214183527491,\n \"seed\": 467493527,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"ab6rp57hjTIAFyuA5YDX3\",\n \"focus\": -0.38026620661717697,\n \"gap\": 5.951103617412457\n },\n \"endBinding\": {\n \"elementId\": \"NU2JREi3xUp2weJX7bAJm\",\n \"focus\": -0.3924820723414731,\n \"gap\": 4.047414674024026\n },\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 127.05145994593613,\n -81.64214183527491\n ]\n ]\n },\n {\n \"type\": \"arrow\",\n \"version\": 1061,\n \"versionNonce\": 373937049,\n \"isDeleted\": false,\n \"id\": \"uL_8YGqxLi1BSSu7iorS0\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 3017.1352444152494,\n \"y\": 485.7509023749336,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 131.13784455637045,\n \"height\": 79.77723278152466,\n \"seed\": 694351799,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"oBiKdnd5XAQbDcmua_vGo\",\n \"focus\": 0.36100717181166037,\n \"gap\": 6.737941957899125\n },\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -131.13784455637045,\n -79.77723278152466\n ]\n ]\n },\n {\n \"type\": \"rectangle\",\n \"version\": 884,\n \"versionNonce\": 715230839,\n \"isDeleted\": false,\n \"id\": \"9R7ufcjq6d6ZoaX6OOK3o\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dotted\",\n \"roughness\": 2,\n \"opacity\": 80,\n \"angle\": 0,\n \"x\": 3182.2569617660924,\n \"y\": 680.203283216632,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 122.90006131207839,\n \"height\": 71.15266707541379,\n \"seed\": 1471736023,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"kNNMfGBdZJNd7W4BIDTeu\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"arrow\",\n \"version\": 1139,\n \"versionNonce\": 1960704121,\n \"isDeleted\": false,\n \"id\": \"kNNMfGBdZJNd7W4BIDTeu\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 2,\n \"opacity\": 80,\n \"angle\": 0,\n \"x\": 3211.73608862625,\n \"y\": 675.4169387790005,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 131.91444418511495,\n \"height\": 123.69303086041371,\n \"seed\": 1685304823,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"9R7ufcjq6d6ZoaX6OOK3o\",\n \"focus\": 0.11142388738137558,\n \"gap\": 4.786344437631556\n },\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -131.91444418511495,\n -123.69303086041371\n ]\n ]\n },\n {\n \"id\": \"xePwhue-IWkp_f5CVUeM2\",\n \"type\": \"text\",\n \"x\": 151.58575623324356,\n \"y\": 27.31988679682287,\n \"width\": 180.4061302681993,\n \"height\": 28.585478387566784,\n \"angle\": 5.973411447994389,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"seed\": 1029430807,\n \"version\": 222,\n \"versionNonce\": 1249290135,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false,\n \"text\": \"Kec(key), RLP(v)\",\n \"fontSize\": 22.868382710053428,\n \"fontFamily\": 1,\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Kec(key), RLP(v)\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"text\",\n \"version\": 243,\n \"versionNonce\": 995787097,\n \"isDeleted\": false,\n \"id\": \"lI3ZZxTux_awzpnCfby1c\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 5.973411447994389,\n \"x\": 582.6921694157284,\n \"y\": -93.39607988008274,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 180.40613026819932,\n \"height\": 28.585478387566784,\n \"seed\": 534366295,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 22.86838271005343,\n \"fontFamily\": 1,\n \"text\": \"Kec(key), RLP(v)\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Kec(key), RLP(v)\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"text\",\n \"version\": 249,\n \"versionNonce\": 512466103,\n \"isDeleted\": false,\n \"id\": \"6TvwjC9y45IFjyS4ohzzW\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 5.973411447994389,\n \"x\": 312.28964082691584,\n \"y\": -224.7161946103714,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 180.4061302681993,\n \"height\": 28.585478387566784,\n \"seed\": 1994618489,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 22.868382710053428,\n \"fontFamily\": 1,\n \"text\": \"Kec(key), RLP(v)\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Kec(key), RLP(v)\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"text\",\n \"version\": 269,\n \"versionNonce\": 387116601,\n \"isDeleted\": false,\n \"id\": \"092eairx9C6Z1g4AItDX9\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 5.973411447994389,\n \"x\": 856.5333877908561,\n \"y\": -412.20379378644486,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 164.6283524904219,\n \"height\": 26.085478387566823,\n \"seed\": 14915415,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 20.868382710053478,\n \"fontFamily\": 1,\n \"text\": \"Kec(key), RLP(v)\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Kec(key), RLP(v)\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"text\",\n \"version\": 291,\n \"versionNonce\": 1250225623,\n \"isDeleted\": false,\n \"id\": \"L5rJs7lVYpzUIlEOZsdUA\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 5.973411447994389,\n \"x\": 840.6340637999269,\n \"y\": -176.12000108638725,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 164.6283524904219,\n \"height\": 26.085478387566823,\n \"seed\": 1148590073,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 20.868382710053478,\n \"fontFamily\": 1,\n \"text\": \"Kec(key), RLP(v)\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Kec(key), RLP(v)\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"text\",\n \"version\": 340,\n \"versionNonce\": 1055571737,\n \"isDeleted\": false,\n \"id\": \"xjvHFkFZFtwsEnP5SCT7G\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"angle\": 5.973411447994389,\n \"x\": 1108.8309890236671,\n \"y\": -256.71410323122,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 164.6283524904219,\n \"height\": 26.085478387566823,\n \"seed\": 1016375321,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 20.868382710053478,\n \"fontFamily\": 1,\n \"text\": \"Kec(key), RLP(v)\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Kec(key), RLP(v)\",\n \"lineHeight\": 1.25\n },\n {\n \"id\": \"MQ1JS_Ai8PRa2Z3H4qt5f\",\n \"type\": \"rectangle\",\n \"x\": 2844.134333888306,\n \"y\": -2153.719795560891,\n \"width\": 653.3333333333329,\n \"height\": 426.6666666666663,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"seed\": 1343813143,\n \"version\": 41,\n \"versionNonce\": 158800631,\n \"isDeleted\": false,\n \"boundElements\": [\n {\n \"id\": \"jE4UVwVXKRGqT1MPrvFBw\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false\n },\n {\n \"id\": \"IWrwDquT16PMwFEnZf-3c\",\n \"type\": \"text\",\n \"x\": 2914.134333888307,\n \"y\": -2113.7197955608913,\n \"width\": 262.4500020345048,\n \"height\": 99.14859289073226,\n \"angle\": 0,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 4,\n \"strokeStyle\": \"solid\",\n \"roughness\": 2,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"seed\": 1250674233,\n \"version\": 42,\n \"versionNonce\": 1072079895,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1710062878126,\n \"link\": null,\n \"locked\": false,\n \"text\": \"BLOCK\",\n \"fontSize\": 79.31887431258579,\n \"fontFamily\": 1,\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"BLOCK\",\n \"lineHeight\": 1.25\n }\n ],\n \"appState\": {\n \"gridSize\": null,\n \"viewBackgroundColor\": \"#ffffff\"\n },\n \"files\": {}\n}" }, { "path": "docs/images/el-specs/excalidraw/stf_eels.excalidraw", "content": "{\n \"type\": \"excalidraw\",\n \"version\": 2,\n \"source\": \"https://excalidraw.com\",\n \"elements\": [\n {\n \"type\": \"rectangle\",\n \"version\": 1063,\n \"versionNonce\": 870412945,\n \"isDeleted\": false,\n \"id\": \"4zdNFfru-10vyTl049pPG\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 210.4102564102567,\n \"y\": -4.160197592325915,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 236.0912926115698,\n \"height\": 320.0619069940355,\n \"seed\": 2239606,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"RFtq1NGpWBMu91BC3xXs3\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1709582744554,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 719,\n \"versionNonce\": 70355509,\n \"isDeleted\": false,\n \"id\": \"zfAWRLl-9lzTbFwdc4QcF\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 233.87190801773733,\n \"y\": 33.08938619224415,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 222.78334045410156,\n \"height\": 165.10016202731921,\n \"seed\": 452149103,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1709602237926,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 22.013354936975894,\n \"fontFamily\": 1,\n \"text\": \" BlockChain \\n\\n blocks: [Block] \\n chain_id \\n \\n\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \" BlockChain \\n\\n blocks: [Block] \\n chain_id \\n \\n\",\n \"lineHeight\": 1.25,\n \"baseline\": 157\n },\n {\n \"type\": \"line\",\n \"version\": 619,\n \"versionNonce\": 85391473,\n \"isDeleted\": false,\n \"id\": \"_2rxuEknc11XTrbvYQIl2\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 211.01873912317316,\n \"y\": 71.90014152222619,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 233.6573617599043,\n \"height\": 0,\n \"seed\": 1313640431,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1709582744554,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 233.6573617599043,\n 0\n ]\n ]\n },\n {\n \"type\": \"rectangle\",\n \"version\": 1089,\n \"versionNonce\": 910672671,\n \"isDeleted\": false,\n \"id\": \"-BlYqbVZ8UVqLyjT2hX1G\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 239.00894391732845,\n \"y\": 159.52165218219034,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 179.50240031034315,\n \"height\": 142.38495482244167,\n \"seed\": 1718562849,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [],\n \"updated\": 1709582744554,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 1364,\n \"versionNonce\": 959127451,\n \"isDeleted\": false,\n \"id\": \"qNgNHutBsPhAWCp71zpEy\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 247.91758181612204,\n \"y\": 204.6876230312575,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 161.1999969482422,\n \"height\": 87.64682192889167,\n \"seed\": 1668298977,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1709602237926,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 17.529364385778333,\n \"fontFamily\": 1,\n \"text\": \" main trie\\n storage tries\\n snapshots\\n created accounts\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \" main trie\\n storage tries\\n snapshots\\n created accounts\",\n \"lineHeight\": 1.25,\n \"baseline\": 81\n },\n {\n \"type\": \"text\",\n \"version\": 651,\n \"versionNonce\": 441219989,\n \"isDeleted\": false,\n \"id\": \"jPr1v0ofvjta_s5jJb9eP\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 256.04645987898806,\n \"y\": 168.9531342323948,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 65.38333129882812,\n \"height\": 27.685963437696994,\n \"seed\": 680210255,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1709602237927,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 22.148770750157595,\n \"fontFamily\": 1,\n \"text\": \"State\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"State\",\n \"lineHeight\": 1.25,\n \"baseline\": 19\n },\n {\n \"type\": \"line\",\n \"version\": 680,\n \"versionNonce\": 1368805425,\n \"isDeleted\": false,\n \"id\": \"XfGw7T1cWejLgreHbc_Eo\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 242.61742663024484,\n \"y\": 201.50695937342306,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 180.7193657361759,\n \"height\": 0,\n \"seed\": 768049135,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1709582744554,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 180.7193657361759,\n 0\n ]\n ]\n },\n {\n \"type\": \"rectangle\",\n \"version\": 1443,\n \"versionNonce\": 1852125275,\n \"isDeleted\": false,\n \"id\": \"798DjR28cWq2sdqVouoV6\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1122.3994951610239,\n \"y\": -185.06191866782314,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 286.09129261156977,\n \"height\": 337.0619069940355,\n \"seed\": 1277566223,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [],\n \"updated\": 1709602262792,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 1043,\n \"versionNonce\": 682913019,\n \"isDeleted\": false,\n \"id\": \"zmR_ggNOuz-i6qrhNSCM5\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1136.29507762017,\n \"y\": -155.81233488325307,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 300.23333740234375,\n \"height\": 165.10016202731924,\n \"seed\": 513647407,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [\n {\n \"id\": \"kas_kTltQ1OWZK-_ZfHCQ\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1709602262792,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 22.013354936975897,\n \"fontFamily\": 1,\n \"text\": \" BlockChain' \\n\\n(blocks + block) [-255:] \\n chain_id \\n \\n\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \" BlockChain' \\n\\n(blocks + block) [-255:] \\n chain_id \\n \\n\",\n \"lineHeight\": 1.25,\n \"baseline\": 157\n },\n {\n \"type\": \"line\",\n \"version\": 1033,\n \"versionNonce\": 1695787579,\n \"isDeleted\": false,\n \"id\": \"SFMipSqJd09B2_sW8NyWy\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1133.8334260126899,\n \"y\": -114.21854497910385,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 265.65736175990423,\n \"height\": 1,\n \"seed\": 1618961743,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1709602262792,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 265.65736175990423,\n -1\n ]\n ]\n },\n {\n \"type\": \"rectangle\",\n \"version\": 1437,\n \"versionNonce\": 456698587,\n \"isDeleted\": false,\n \"id\": \"AxIHs1FRjuyFqXXcMNwil\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1161.823630806845,\n \"y\": -26.59703431913971,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 179.50240031034315,\n \"height\": 142.38495482244167,\n \"seed\": 556000111,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"kas_kTltQ1OWZK-_ZfHCQ\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1709602262792,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 1711,\n \"versionNonce\": 305436539,\n \"isDeleted\": false,\n \"id\": \"Xrbd0DXSIc-0XaYHmYCoS\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1170.7322687056385,\n \"y\": 18.56893652992744,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 161.1999969482422,\n \"height\": 87.64682192889167,\n \"seed\": 1892916623,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1709602262792,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 17.529364385778333,\n \"fontFamily\": 1,\n \"text\": \" main trie\\n storage tries\\n snapshots\\n created accounts\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \" main trie\\n storage tries\\n snapshots\\n created accounts\",\n \"lineHeight\": 1.25,\n \"baseline\": 81\n },\n {\n \"type\": \"text\",\n \"version\": 999,\n \"versionNonce\": 1749676059,\n \"isDeleted\": false,\n \"id\": \"Khb-NXHp_7Z6w4FcGnR_p\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1178.8611467685046,\n \"y\": -17.165552268935244,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 71.28333282470703,\n \"height\": 27.685963437696994,\n \"seed\": 1120342959,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [\n {\n \"id\": \"kas_kTltQ1OWZK-_ZfHCQ\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1709602262793,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 22.148770750157595,\n \"fontFamily\": 1,\n \"text\": \"State'\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"State'\",\n \"lineHeight\": 1.25,\n \"baseline\": 19\n },\n {\n \"type\": \"line\",\n \"version\": 1026,\n \"versionNonce\": 1332425915,\n \"isDeleted\": false,\n \"id\": \"PSS9Yp2RW3WF73S8h8Sor\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1162.4321135197615,\n \"y\": 15.388272872093069,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 180.7193657361759,\n \"height\": 0,\n \"seed\": 254199247,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1709602262793,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 180.7193657361759,\n 0\n ]\n ]\n },\n {\n \"type\": \"arrow\",\n \"version\": 2663,\n \"versionNonce\": 1945673695,\n \"isDeleted\": false,\n \"id\": \"RFtq1NGpWBMu91BC3xXs3\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 446.9778934380746,\n \"y\": 102.7514334061351,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 241.97897440189593,\n \"height\": 115.68896952487248,\n \"seed\": 348232385,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1709582744554,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"4zdNFfru-10vyTl049pPG\",\n \"focus\": 0.016378698809655003,\n \"gap\": 1\n },\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 241.97897440189593,\n -115.68896952487248\n ]\n ]\n },\n {\n \"type\": \"rectangle\",\n \"version\": 737,\n \"versionNonce\": 1565069713,\n \"isDeleted\": false,\n \"id\": \"VdgNr7i2p8_aZmyN829C_\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 348.67720512153085,\n \"y\": -378.713675213675,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 165.46252660997408,\n \"height\": 186.1957101524238,\n \"seed\": 1719714549,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"PVjCUtkjcPDNm47AA-OOI\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1709582744554,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 709,\n \"versionNonce\": 1595431509,\n \"isDeleted\": false,\n \"id\": \"o1cg2lFB7VKMujBP88pWd\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 367.4080365946305,\n \"y\": -356.73271067145816,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 133.89999389648438,\n \"height\": 171.2878836859714,\n \"seed\": 132392955,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [\n {\n \"id\": \"PVjCUtkjcPDNm47AA-OOI\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1709602237930,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 19.575758135539587,\n \"fontFamily\": 1,\n \"text\": \" Block \\n\\n header \\n ommers \\n transactions\\n withdrawals \\n\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \" Block \\n\\n header \\n ommers \\n transactions\\n withdrawals \\n\",\n \"lineHeight\": 1.25,\n \"baseline\": 164\n },\n {\n \"type\": \"line\",\n \"version\": 736,\n \"versionNonce\": 2117252977,\n \"isDeleted\": false,\n \"id\": \"uO9UmNWIemInasRcXEBFo\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 349.28568783444734,\n \"y\": -320.83048523547546,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 164.9049810376674,\n \"height\": 0.6084827129164658,\n \"seed\": 439276155,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1709582744554,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 164.9049810376674,\n 0.6084827129164658\n ]\n ]\n },\n {\n \"type\": \"arrow\",\n \"version\": 1812,\n \"versionNonce\": 1024160799,\n \"isDeleted\": false,\n \"id\": \"PVjCUtkjcPDNm47AA-OOI\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 449.12969429792383,\n \"y\": -190.95679351583942,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 239.8792192946571,\n \"height\": 180.9238930371343,\n \"seed\": 718450523,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1709582744554,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"VdgNr7i2p8_aZmyN829C_\",\n \"focus\": 0.5227984399263346,\n \"gap\": 1.5611715454117956\n },\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 239.8792192946571,\n 180.9238930371343\n ]\n ]\n },\n {\n \"type\": \"rectangle\",\n \"version\": 704,\n \"versionNonce\": 1194371423,\n \"isDeleted\": false,\n \"id\": \"610XKp8JphvhDiqKbnX7z\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 160.01709401709422,\n \"y\": -475.4914529914528,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 1372.5555555555557,\n \"height\": 926.6666666666665,\n \"seed\": 1576819035,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [],\n \"updated\": 1709582745385,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 627,\n \"versionNonce\": 15786363,\n \"isDeleted\": false,\n \"id\": \"dst4Ibur8UPw58-hpXmPf\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 1029.905982905983,\n \"y\": -430.6350174326201,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 347.26666259765625,\n \"height\": 90,\n \"seed\": 422244251,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1709602237931,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 36,\n \"fontFamily\": 1,\n \"text\": \"EXECUTION LAYER\\n(EELS Perspective)\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"EXECUTION LAYER\\n(EELS Perspective)\",\n \"lineHeight\": 1.25,\n \"baseline\": 77\n },\n {\n \"type\": \"ellipse\",\n \"version\": 777,\n \"versionNonce\": 1588023797,\n \"isDeleted\": false,\n \"id\": \"ATiac8euV98ERTVU-2QsZ\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 491.699633699634,\n \"y\": -299.58669108669073,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 1028.6966611136595,\n \"height\": 572.1598998435269,\n \"seed\": 938642684,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1709602276177,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 449,\n \"versionNonce\": 526718453,\n \"isDeleted\": false,\n \"id\": \"1zWnbtvohUyK1fO6trjzk\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 738.25002045987,\n \"y\": -242.94568802410583,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 461.8999938964844,\n \"height\": 35,\n \"seed\": 370417909,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1709602300545,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 28,\n \"fontFamily\": 1,\n \"text\": \"STATE TRANSITION FUNCTION\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"STATE TRANSITION FUNCTION\",\n \"lineHeight\": 1.25,\n \"baseline\": 25\n },\n {\n \"type\": \"diamond\",\n \"version\": 488,\n \"versionNonce\": 1421820177,\n \"isDeleted\": false,\n \"id\": \"qewi2Oq-xvCaaEGzUNDFJ\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 680.6237989780489,\n \"y\": -81.00597043782057,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 154.2516722365357,\n \"height\": 136,\n \"seed\": 658208597,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [\n {\n \"type\": \"text\",\n \"id\": \"PXZ6_rntGzqoL_rEuul0G\"\n },\n {\n \"id\": \"kas_kTltQ1OWZK-_ZfHCQ\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1709582744554,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 636,\n \"versionNonce\": 1251857535,\n \"isDeleted\": false,\n \"id\": \"PXZ6_rntGzqoL_rEuul0G\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 730.678383831006,\n \"y\": -38.005970437820565,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 54.016666412353516,\n \"height\": 50,\n \"seed\": 783135829,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1709582744554,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 20,\n \"fontFamily\": 1,\n \"text\": \"Block\\nValid?\",\n \"textAlign\": \"center\",\n \"verticalAlign\": \"middle\",\n \"containerId\": \"qewi2Oq-xvCaaEGzUNDFJ\",\n \"originalText\": \"Block\\nValid?\",\n \"lineHeight\": 1.25,\n \"baseline\": 45\n },\n {\n \"type\": \"arrow\",\n \"version\": 1202,\n \"versionNonce\": 456332699,\n \"isDeleted\": false,\n \"id\": \"kas_kTltQ1OWZK-_ZfHCQ\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0.21865975843474494,\n \"x\": 835.2524396971147,\n \"y\": 23.313054260310984,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 282.4265371044114,\n \"height\": 59.35706247007869,\n \"seed\": 84529905,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1709602262792,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"qewi2Oq-xvCaaEGzUNDFJ\",\n \"focus\": 0.052549933141040436,\n \"gap\": 1.8126612939902813\n },\n \"endBinding\": {\n \"elementId\": \"zmR_ggNOuz-i6qrhNSCM5\",\n \"focus\": -0.8314937817848065,\n \"gap\": 15.515687921854578\n },\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 172.04761379629326,\n -35.157969122578976\n ],\n [\n 282.4265371044114,\n -59.35706247007869\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 564,\n \"versionNonce\": 216857115,\n \"isDeleted\": false,\n \"id\": \"ftxhghRIe4V5pr-DyIUpH\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0.07546976471228106,\n \"x\": 830.9893946018796,\n \"y\": -30.907037769962745,\n \"strokeColor\": \"#2f9e44\",\n \"backgroundColor\": \"transparent\",\n \"width\": 35.96666717529297,\n \"height\": 25,\n \"seed\": 2113878485,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1709602237932,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 20,\n \"fontFamily\": 1,\n \"text\": \"YES\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"YES\",\n \"lineHeight\": 1.25,\n \"baseline\": 18\n },\n {\n \"type\": \"arrow\",\n \"version\": 1815,\n \"versionNonce\": 519893201,\n \"isDeleted\": false,\n \"id\": \"1uboxoVWTsg8a4enZDLVi\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 759.3916861989013,\n \"y\": 50.761135683835164,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 5,\n \"height\": 276.6521732294741,\n \"seed\": 274972149,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1709582744554,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": {\n \"elementId\": \"qPYfAbYeb9aNTY8X3FMVm\",\n \"focus\": 1.240876470051702,\n \"gap\": 4.156278057562417\n },\n \"endBinding\": {\n \"elementId\": \"Ws8AItFqJNGM219aGQamZ\",\n \"focus\": 0.1037345787577261,\n \"gap\": 4\n },\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 5,\n 166.65217322947407\n ],\n [\n 1.953442812754929,\n 276.6521732294741\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 465,\n \"versionNonce\": 1074497813,\n \"isDeleted\": false,\n \"id\": \"qPYfAbYeb9aNTY8X3FMVm\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 763.5479642564637,\n \"y\": 51.290046541006234,\n \"strokeColor\": \"#ff8787\",\n \"backgroundColor\": \"transparent\",\n \"width\": 27.399999618530273,\n \"height\": 25,\n \"seed\": 923894261,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [\n {\n \"id\": \"1uboxoVWTsg8a4enZDLVi\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1709602237932,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 20,\n \"fontFamily\": 1,\n \"text\": \"NO\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"NO\",\n \"lineHeight\": 1.25,\n \"baseline\": 18\n },\n {\n \"type\": \"rectangle\",\n \"version\": 800,\n \"versionNonce\": 1957211825,\n \"isDeleted\": false,\n \"id\": \"Ws8AItFqJNGM219aGQamZ\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 640.699633699634,\n \"y\": 331.41330891330927,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 217.00000000000017,\n \"height\": 50.999999999999986,\n \"seed\": 1995747749,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 3\n },\n \"boundElements\": [\n {\n \"id\": \"1uboxoVWTsg8a4enZDLVi\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1709582744554,\n \"link\": null,\n \"locked\": false\n },\n {\n \"type\": \"text\",\n \"version\": 648,\n \"versionNonce\": 1058864827,\n \"isDeleted\": false,\n \"id\": \"WCVB0a-Xsb-Ky8uyAUEzP\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 666.699633699634,\n \"y\": 344.41330891330927,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 133.98333740234375,\n \"height\": 25,\n \"seed\": 759341957,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [\n {\n \"id\": \"1uboxoVWTsg8a4enZDLVi\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1709602237932,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 20,\n \"fontFamily\": 1,\n \"text\": \"Reject Block \",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Reject Block \",\n \"lineHeight\": 1.25,\n \"baseline\": 18\n },\n {\n \"type\": \"text\",\n \"version\": 319,\n \"versionNonce\": 205758069,\n \"isDeleted\": false,\n \"id\": \"J0Vmlud-_j-SVCTRNmweQ\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 829.699633699634,\n \"y\": -67.8366910866907,\n \"strokeColor\": \"#1e1e1e\",\n \"backgroundColor\": \"transparent\",\n \"width\": 277.3166809082031,\n \"height\": 125,\n \"seed\": 2055777988,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1709602237933,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 20,\n \"fontFamily\": 1,\n \"text\": \"1. Append block to blockchain\\n \\n \\n2. discard blocks preceding\\n the recent 255\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"1. Append block to blockchain\\n \\n \\n2. discard blocks preceding\\n the recent 255\",\n \"lineHeight\": 1.25,\n \"baseline\": 118\n }\n ],\n \"appState\": {\n \"gridSize\": null,\n \"viewBackgroundColor\": \"#ffffff\"\n },\n \"files\": {}\n}" }, { "path": "docs/index.html", "content": "\n\n\n\n \n Protocol Wiki\n \n \n \n \n \n\n \n \n \n \n \n \n\n \n \n \n \n \n\n \n\n \n\n \n \n \n \n \n\n \n \n \n\n \n \n\n\n\n
\n \n \n\n \n \n \n \n\n \n \n\n \n \n\n \n \n\n \n \n\n \n \n\n \n \n\n \n \n \n \n\n \n \n\n \n \n \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n" }, { "path": "docs/readme.md", "content": "# **Welcome to the Protocol!**\n\nThe EPF Wiki is a collection of technical resources about the Ethereum protocol. It's home to all resources from EPF Study Group and the Protocol Wiki. These include technical information covering all core protocol domains and ongoing research. It's dedicated to serve aspiring core contributors and does not cover any smart contract or other high level development. This serves also as an introduction for Protocol Fellowship for those who wish to dive even deeper and work directly on Ethereum protocol. \n\n## Protocol Study Group\n\nEthereum Protocol Study Group (EPS) is an open study program for anyone interested in learning about internals of the protocol. The study group resources are available as self study curriculum but there is also live Study Group organized annually between February-April. Following blog.ethereum.org for announcements to join a community of students. \n\n**Study Group 2026** is starting on February 23rd with 8 weeks of content. Learn with us at [study.epf.wiki](https://study.epf.wiki)\n\n> The study group is not just a list of resources but a community of people maintaining them and learning about the core protocol. **Join the community in our [Discord server](https://discord.gg/8RPnPGEQtJ)**.\n\n## Protocol Wiki\n\nProtocol Wiki is a technical documentation of the main parts of Ethereum core development and research. It guides anyone interested in looking under the hood of the protocol and contributing. The wiki is maintained by the community formed around the study group and keeps following the latest research. \n\n> :warning: Protocol Wiki is still under construction, many important topics are not fully covered. **If you find a missing content or issues, don't hesitate to [contribute](contributing.md)**.\n>\n>\n\n## Protocol Fellowship\n\n[Ethereum Protocol Fellowship](/wiki/epf) (EPF) is a program for developers and researchers deeply interested in working on the protocol. It's an opportunity to work directly with client teams on their and contribute by building projects with larger scope. It's 5 month program, normally organized annually June-November. Stay tuned for announcement for applications. \n\n\n![](https://raw.githubusercontent.com/eth-protocol-fellows/protocol-studies/wiki-pages/docs/images/epf7_hero.png)\n" }, { "path": "docs/resources.md", "content": "# Resources\n\nThis wiki should not copy other existing materials, only collect them in the right context. Use this page to \n\nhttps://github.com/tvanepps/EthereumDiscordGuidebook \n\nhttps://inevitableeth.com/" }, { "path": "docs/topics.md", "content": "# Topics\n\n### #(##) [A](#a)|[B](#b)|[C](#c)|[D](#d)|[E](#e)|[F](#f)|[G](#g)|[H](#h)|[I](#i)|[J](#j)|[K](#k)|[L](#l)|[M](#m)|[N](#n)|[O](#o)|[P](#p)|[Q](#q)|[R](#r)|[S](#s)|[T](#t)|[U](#u)|[V](#v)|[W](#w)|[X](#x)|[Y](#y)|[Z](#z)\n\n### #\n[1559]\n[4844]\n\n### A\n[AA]()\n[ASE]\n[Attestations]\n### B\n[BFT]\n[BLS]\n\n### C\n[Consensus layer]\n[Commitments]\n\n### D\n[Design principles]\n[DAS]\n[Danksharding]\n\n### E \n[Encodings]\n[EOF]\n[EVM]\n[Execution layer]\n\n### F\n[Forkchoice]\n\n### G\n[Gas metering]\n\n### H\n[History expiry]() \n\n### J\n[JSON-RPC](/wiki/EL/JSON-RPC.md)\n\n### K\n\n\n### L\n[Light clients]\n\n### M\n[MEV]\n[Mempool]\n[MPT]\n\n### P\n[p2p]\n[PBS]\n\n### R\n[RLP]\n[Roadmap]\n\n### S\n[Statelessness]\n[SSF]\n[SSZ]\n\n### T\n[Transactions]\n\n### U\n[Unix philosophy]\n\n### V\n[Verkle trees]\n[VDFs]\n\n### W\nWeak subjectivity\n\n### Z\nZK proofs" }, { "path": "docs/wiki/CL/SSZ.md", "content": "# Simple Serialize (SSZ)\n\n## Overview\n\n\nSimple Serialize (SSZ) is a serialization and [Merkleization](/wiki/CL/merkleization.md) scheme designed specifically for Ethereum's Beacon Chain. SSZ replaces the [RLP serialization](/wiki/EL/RLP.md) used on the execution layer (EL) everywhere across the consensus layer (CL) except the [peer discovery protocol](https://github.com/ethereum/devp2p). Its development and adoption are aimed at enhancing the efficiency, security, and scalability of Ethereum's CL.\n\nThis document is about SSZ Serialization. You can learn more about SSZ merkleization at the [merkleization wiki page](/wiki/CL/merkleization.md).\n\n\n## SSZ Tools\n\nThere are many tools available for SSZ. Here is a [full list](https://github.com/ethereum/consensus-specs/issues/2138) of SSZ tools. Below are some of the popular ones:\n\n- [py-ssz](https://github.com/ethereum/py-ssz)\n- [dafny](https://github.com/ConsenSys/eth2.0-dafny)\n- [remerkleable](https://github.com/protolambda/remerkleable)\n- [fastssz](https://github.com/ferranbt/fastssz/)\n- [rust-ssz](https://github.com/ralexstokes/ssz-rs)\n\n## SSZ VS RLP Serialization\n\n| CRITERIA | COMPACT | EXPRESSIVENESS | HASHING | INDEXING |\n|------------|---------|----------------|----------|----------|\n| RLP | Yes | Flexible | Possible | No |\n| SSZ | No | Yes | Yes | Poor |\n\n_Table: SSZ VS RLP Comparison by [Piper Merriam](https://twitter.com/pipermerriam)._\n\n**Expressiveness**:\n- **SSZ**: Supports all necessary data types directly without the need for additional abstraction layers. This makes SSZ inherently more straightforward and robust for handling complex data structures used in Ethereum PoS.\n- **RLP**: Limited to dynamic length byte strings and lists. Additional data types are only supported through abstraction layers, which can introduce complexity and potential inefficiencies.\n\n**Hashing**:\n- **SSZ**: Facilitates efficient hashing and re-hashing of objects, particularly beneficial for operations that require frequent updates to data states, such as those in sharding and stateless clients. This efficiency is crucial for maintaining blockchain integrity and performance.\n- **RLP**: While hashing is possible, it does not offer the same performance optimizations, especially when data structures undergo minor modifications.\n\n**Indexing**:\n- **SSZ**: Although indexing is described as 'poor', SSZ supports some level of direct access to serialized data without full deserialization, which is beneficial for certain operations within the blockchain.\n- **RLP**: Does not support efficient indexing, potentially leading to `O(N)` complexity when accessing internal data, which can be a significant drawback for performance on large-scale networks.\n\n**Data Type Compatibility**:\n- **SSZ**: Designed to be fully compatible with the data types and structures used within the Ethereum protocol, enhancing its utility for consensus mechanisms and network operations.\n- **RLP**: While flexible, the need for additional layers to support various data types can lead to inefficiencies and increased complexity in implementation.\n\n**Deterministic Serialization**:\n- **SSZ**: Provides deterministic serialization results, ensuring that the same data structure serializes to the exact same byte sequence every time, which is crucial for consensus reliability.\n- **RLP**: RLP also provides deterministic serialization results.\n\n\nFor these reasons, there is a strong effort in Ethereum to completely migrate to SSZ serialization for everything and stop the usage of RLP serialization.\n\n\n## How SSZ Works - Basic Types\n\nHere’s how SSZ handles the serialization and deserialization of the basic types:\n\n```mermaid\nflowchart TD\n A[Start Serialization] --> B[Choose Data Type]\n B --> C[Unsigned Integer]\n B --> D[Boolean]\n \n C --> E[Convert Integer to \\nLittle-Endian Byte Array]\n E --> F[Serialized Output for Integer]\n \n D --> G[\"Convert Boolean to Byte \\n(True to 0x01, False to 0x00)\"]\n G --> H[Serialized Output for Boolean]\n \n```\n\n_Figure: Serialization Process for Basic Types._\n\n\n```mermaid\nflowchart TD\n A[Start Deserialization] --> B[Determine Data Type]\n B --> C[Unsigned Integer]\n B --> D[Boolean]\n \n C --> E[Read Little-Endian Byte Array]\n E --> F[Reconstruct Original Integer Value]\n F --> G[Deserialized Integer Output]\n \n D --> H[Read Byte]\n H --> I[\"Translate Byte to Boolean \\n(0x01 to True, 0x00 to False)\"]\n I --> J[Deserialized Boolean Output]\n \n```\n\n_Figure: Deserialization Process for Basic Types._\n\n### Unsigned Integers\n\nUnsigned integers (`uintN`) in SSZ are denoted where `N` can be any of 8, 16, 32, 64, 128, or 256 bits. These integers are serialized directly to their little-endian byte representation, which is a form well-suited for most modern computer architectures and facilitates easier manipulation at the byte level.\n\n**Serialization Process for Unsigned Integers:**\n\n- **Input**: Take an unsigned integer of type `uintN`.\n- **Convert to Bytes**: Convert the integer into a byte array of length `N/8`. For instance, `uint16` represents 2 bytes.\n- **Apply Little-Endian Format**: Arrange the bytes in little-endian order, where the least significant byte is stored first.\n- **Output**: The resulting byte array is the serialized form of the integer.\n\n**Example:**\n- Integer `1025` as `uint16` would be serialized to `01 04` in hexadecimal. First, convert `1025` to hex which gives `0x0401`. In little-endian format, the least significant byte (LSB) comes first. So, `0x0401` in little-endian is `01 04`. The byte array `[01, 04]` is the serialized output.\n\n**Deserialization Process for Unsigned Integers:**\n\n- **Input**: Read the byte array representing a serialized `uintN`.\n- **Read Little-Endian Bytes**: Interpret the bytes in little-endian order to reconstruct the integer value.\n- **Output**: Convert the byte array back into the integer.\n\n**Example:**\n- Byte array `01 04` (in hex) is deserialized to the integer `1025`. Read the first byte `01` as the lower part and `04` as the higher part of the integer. It translates back to `0401` in hex when reassembled in big-endian format for human readability, which equals 1025 in decimal.\n\n### Booleans\n\nBooleans in SSZ are quite straightforward, with each boolean represented as a single byte.\n\n**Serialization Process for Booleans:**\n\n- **Input**: Take a boolean value (`True` or `False`).\n- **Convert to Byte**: \n - If the boolean is `True`, serialize it as `01` (in hex).\n - If the boolean is `False`, serialize it as `00`.\n- **Output**: The resulting single byte is the serialized form of the boolean.\n\n**Example:**\n- `True` becomes `01`.\n- `False` becomes `00`.\n\n**Deserialization Process for Booleans:**\n\n- **Input**: Read a single byte.\n- **Interpret the Byte**: \n - A byte of `01` indicates `True`.\n - A byte of `00` indicates `False`.\n- **Output**: The boolean value corresponding to the byte.\n\n**Example:**\n- Byte `01` is deserialized to `True`.\n- Byte `00` is deserialized to `False`.\n\nWe can run SSZ serialization and deserialization commands using the python Eth PoS spec as per the [instructions](https://eth2book.info/capella/appendices/running/) and verify the above byte arrays.\n\n```python\n>>> from eth2spec.utils.ssz.ssz_typing import uint64, boolean\n# Serializing \n>>> uint64(1025).encode_bytes().hex()\n'0104000000000000'\n>>> boolean(True).encode_bytes().hex()\n'01'\n>>> boolean(False).encode_bytes().hex()\n'00' \n\n# Deserializing \n>>> print(uint64.decode_bytes(bytes.fromhex('0104000000000000')))\n1025\n>>> print(boolean.decode_bytes(bytes.fromhex('01')))\n1\n>>> print(boolean.decode_bytes(bytes.fromhex('00')))\n0\n```\n\n## How SSZ Works on Composite Types\n\n### Vectors\n\nVectors in SSZ are used to handle fixed-length collections of homogeneous elements. Here’s a detailed breakdown of how SSZ handles the serialization and deserialization of vectors.\n\n**SSZ Serialization for Vectors**\n\n```mermaid\nflowchart TD\n A[Start Serialization] --> B[Define Vector with Type and Length]\n B --> C[Serialize Each Element]\n C --> D[\"Convert Each Element to \\nByte Array (Little-Endian)\"]\n D --> E[Concatenate All Byte Arrays]\n E --> F[Output Serialized Vector]\n \n```\n\n_Figure: SSZ Serialization for Vectors._\n\n\n**Fixed-Length Definition**: \n- Vectors are defined with a specific length and type of elements they can hold, such as `Vector[uint64, 4]` for a vector containing four 64-bit unsigned integers.\n\n**Element Serialization**:\n- Each element in the vector is serialized independently according to its type. \n- For basic types like integers or booleans, this means converting each element to its byte representation. \n- If the elements are composite types, each element is serialized according to its specific serialization rules.\n\n**Concatenation**:\n- The serialized outputs of each element are concatenated in the order they appear in the vector. \n- Since the length of the vector and the size of each element are known and fixed, no additional metadata (like length prefixes) is needed in the serialized output.\n\n**Example:**\n- For a `Vector[uint64, 3]` with the elements `[256, 512, 768]`, each element is 64 bits or 8 bytes long. The serialization would proceed as follows:\n\n**Convert Each Integer to Little-Endian Byte Array**:\n- `256` as `uint64` becomes `00 01 00 00 00 00 00 00`.\n- `512` as `uint64` becomes `00 02 00 00 00 00 00 00`.\n- `768` as `uint64` becomes `00 03 00 00 00 00 00 00`.\n\n**Concatenate These Byte Arrays**:\n- The resulting concatenated byte array will be `00 01 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00 03 00 00 00 00 00 00`.\n\n**Serialized Output**:\n- `00 01 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00 03 00 00 00 00 00 00`.\n\n\n**SSZ Deserialization for Vectors**\n\n```mermaid\nflowchart TD\n A[Start Deserialization] --> B[Receive Serialized Byte Stream]\n B --> C[Identify and Split Byte Stream \\nBased on Element Size]\n C --> D[Deserialize Each Byte Segment\\n to Its Original Type]\n D --> E[Reassemble Elements into Vector]\n E --> F[Output Deserialized Vector]\n \n```\n\n_Figure: SSZ Deserialization for Vectors._\n\n\n**Fixed-Length Utilization**:\n- The deserializer uses the predefined length and type of the vector to parse the serialized data.\n- It knows exactly how many bytes each element takes and how many elements are in the vector.\n\n**Element Deserialization**:\n- The byte stream is split into segments corresponding to the size of each element.\n- Each segment is deserialized independently according to the type of elements in the vector.\n\n**Reconstruction**:\n- The elements are reconstructed into their original form (e.g., converting byte arrays back into integers or other specified types).\n- These elements are then aggregated to reform the original vector.\n\n**Example:**\n- Given the serialized data for a `Vector[uint64, 3]`\n- Serialized Byte Array: `00 01 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00 03 00 00 00 00 00 00`.\n\n**Parse the Data into Segments**:\n- Each segment consists of 8 bytes.\n- First segment: `00 01 00 00 00 00 00 00` → Represents the integer 256.\n- Second segment: `00 02 00 00 00 00 00 00` → Represents the integer 512.\n- Third segment: `00 03 00 00 00 00 00 00` → Represents the integer 768.\n\n**Convert Each Segment from a Little-Endian Byte Array Back to an Integer**:\n- Using little-endian format, each byte array is read and converted back into the respective `uint64` integer.\n\n**Reconstruction**:\n- The reconstructed vector is `[256, 512, 768]`.\n\nWe can run and verify it in python like below:\n\n```python\n>>> from eth2spec.utils.ssz.ssz_typing import uint8, uint16, Vector\n>>> Vector[uint16, 3](256, 512, 768).encode_bytes().hex()\n'000100000000000000020000000000000003000000000000'\n>>> print(Vector[uint64, 3].decode_bytes(bytes.fromhex('000100000000000000020000000000000003000000000000')))\nVector[uint64, 3]<>(256, 512, 768)\n>>> \n\n```\n\n### Lists\n\nLists in SSZ are crucial for managing variable-length collections of homogeneous elements within a specified maximum length (`N`). This flexibility allows for dynamic management of the data structures such as transaction sets or variable state components, adapting to the changing needs of the network.\n\n**SSZ Serialization for Lists**\n\n```mermaid\nflowchart TD\n A[Start Serialization] --> B[Define List with Type and Max Length]\n B --> C[Serialize Each Element]\n C --> D[\"Convert Each Element to \\nByte Array (Little-Endian)\"]\n D --> E[Concatenate All Byte Arrays]\n E --> F[Optional: Include Length Metadata]\n F --> G[Output Serialized List]\n \n```\n\n_Figure: SSZ Serialization for Lists._\n\n**Define the List**: \n- Lists in SSZ are defined with a specific element type and a maximum length, noted as `List[type, N]`. This definition not only constrains the list's maximum capacity but also informs how elements should be serialized.\n\n**Element Serialization**:\n- Each element in the list is serialized based on its type. For `uint64` elements, the serialization process involves converting each integer into a byte array.\n\n**Concatenate Serialized Elements**:\n- The outputs of the serialized elements are concatenated sequentially. The total length of the serialized data varies depending on the number of elements present at the time of serialization.\n\n**Include Length Metadata (Optional)**:\n- Depending on the implementation requirements, the length of the list might be explicitly included at the start of the serialized data to aid in parsing and validation during deserialization.\n\n**Example**: \n- For a `List[uint64, 5]` containing the elements `[1024, 2048, 3072]`, the serialization process would involve:\n- Converting each integer to a byte array in little-endian format: `00 04 00 00 00 00 00 00`, `00 08 00 00 00 00 00 00`, `00 0C 00 00 00 00 00 00`.\n- Concatenating these arrays results in: `00 04 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00 0C 00 00 00 00 00 00`.\n\n**SSZ Deserialization for Lists**\n\n```mermaid\nflowchart TD\n A[Start Deserialization] --> B[Receive Serialized Byte Stream]\n B --> C[\"Identify and Split Byte Stream Based \\n on Element Size (8 bytes for uint64)\"]\n C --> D[Deserialize Each Byte Segment to uint64]\n D --> E[Reassemble Elements into List]\n E --> F[Output Deserialized List]\n \n```\n\n_Figure: SSZ Deserialization for Lists._\n\n**Receive Serialized Data**: \n- The serialized byte stream for the list is the input, containing sequences of byte arrays for each element.\n\n**Parse and Deserialize Each Element**:\n- Based on the element type, say `uint64`, parse the serialized stream into 8-byte segments.\n- Convert each byte array from little-endian format back into a `uint64`.\n\n**Reassemble the List**:\n- The deserialized elements are reassembled to recreate the original list.\n\n**Example**: \n- Given the serialized data `00 04 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00 0C 00 00 00 00 00 00` for a `List[uint64, 5]`\n- Split the data into segments of 8 bytes: `00 04 00 00 00 00 00 00`, `00 08 00 00 00 00 00 00`, `00 0C 00 00 00 00 00 00`.\n- Convert each segment from little-endian to integers: `1024`, `2048`, `3072`.\n- The reconstructed list is `[1024, 2048, 3072]`.\n\nWe can run and verify the SSZ for the above example as below:\n\n```python\n>>> from eth2spec.utils.ssz.ssz_typing import uint8, List, Vector\n>>> List[uint64, 5](1024, 2048, 3072).encode_bytes().hex()\n'00040000000000000008000000000000000c000000000000'\n>>> Vector[uint64, 3](1024, 2048, 3072).encode_bytes().hex()\n'00040000000000000008000000000000000c000000000000'\n>>> print(List[uint64, 5].decode_bytes(bytes.fromhex('00040000000000000008000000000000000c000000000000')))\nList[uint64, 5]<>(1024, 2048, 3072)\n>>> \n```\n\nLists are variable sized objects in SSZ they are encoded differently from fixed sized vectors when contained within another object, so there is a small overhead. For example, below `Alice` and `Bob` objects have different encoding.\n\n```python\n>>> from eth2spec.utils.ssz.ssz_typing import uint8, Vector, List, Container\n>>> class Alice(Container):\n... x: List[uint8, 3] # Variable sized\n>>> class Bob(Container):\n... x: Vector[uint8, 3] # Fixed sized\n>>> Alice(x = [1, 2, 3]).encode_bytes().hex()\n'04000000010203'\n>>> Bob(x = [1, 2, 3]).encode_bytes().hex()\n'010203'\n>>> \n```\n\n### Bitvectors\n\nBitvectors in SSZ are used to manage fixed-length sequences of boolean values, typically represented as bits. This data structure is particularly efficient for compactly storing binary data or flags, which are common in Ethereum applications for indicating state conditions, permissions, or other binary settings.\n\n**SSZ Serialization for Bitvectors**\n\n```mermaid\nflowchart TD\n A[Start Serialization] --> B[Define Bitvector of Size N]\n B --> C[Pack Bits into Bytes]\n C --> D[Bits from LSB to\\n MSB within each byte]\n D --> E[Add Padding if N % 8 != 0]\n E --> F[Output Serialized Byte Array]\n \n```\n\n_Figure: SSZ Serialization for Bitvectors._\n\n**Define the Bitvector**: \n- A bitvector in SSZ is defined by its length `N`, which specifies the number of bits. For example, `Bitvector[256]` means a bitvector that contains 256 bits.\n\n**Convert Bits to Bytes**:\n- Each bit in the bitvector represents a boolean value, where `0` corresponds to `False` and `1` to `True`.\n- These bits are packed into bytes, with the least significant bit (LSB) first within each byte. This means the first bit in the bitvector corresponds to the LSB of the first byte.\n\n**Byte Array Formation**:\n- The bits are serialized into a byte array by packing 8 bits into each byte until all bits are accounted for.\n- If `N` is not a multiple of 8, the last byte will contain fewer than 8 bits of data, padded with zeros at the most significant bit positions.\n\n**Example**: For a `Bitvector[10]` with the pattern `1011010010`:\n- The first 8 bits (`10110100`) form the first byte.\n- The remaining 2 bits (`10`) are padded with six zeros to form the second byte: `10000000`.\n- The serialized output is `B4 80` in hexadecimal.\n\n**SSZ Deserialization for Bitvectors**\n\n```mermaid\nflowchart TD\n A[Start Deserialization] --> B[Receive Serialized Byte Array]\n B --> C[Read Each Byte]\n C --> D[Convert Bytes to Bits]\n D --> E[Respect LSB to MSB \\nOrder in Each Byte]\n E --> F[Discard Padding if Present]\n F --> G[Reconstruct Bitvector]\n G --> H[Output Deserialized Bitvector]\n \n```\n\n_Figure: SSZ Deserialization for Bitvectors._\n\n**Read Serialized Byte Array**: \n- Start with a byte array that encodes the bitvector.\n\n**Extract Bits from Bytes**:\n- Convert each byte back into bits. Remember, the bits are stored LSB first within each byte.\n- If the bitvector's length `N` is not a multiple of 8, discard the extraneous padding bits in the final byte.\n\n**Reconstruct the Bitvector**:\n- Reassemble the extracted bits into the original bitvector format, adhering to the specified length `N`.\n\n**Example**: Given the serialized data `B4 80` for a `Bitvector[10]`:\n- Convert `B4` (`10110100` in binary) and `80` (`10000000` in binary) back into bits.\n- Extract the first 10 bits from the binary sequence: `1011010010`.\n- The reconstructed bitvector is `1011010010`.\n\nYou can run and verify it in python as below:\n\n```python\n>>> from eth2spec.utils.ssz.ssz_typing import Bitvector\n>>> Bitvector[8](0,0,1,0,1,1,0,1).encode_bytes().hex()\n'b4'\n>>> Bitvector[8](0,0,0,0,0,0,0,1).encode_bytes().hex()\n'80'\n```\n\nNote that, functionally we could use either `Vector[boolean, N]` or `Bitvector[N]` to represent a list of bits. However, the latter will have a serialization up to eight times shorter in practice since the former will use a whole byte per bit.\n\n```python\n>>> from eth2spec.utils.ssz.ssz_typing import Vector, Bitvector, boolean\n>>> Bitvector[5](1,0,1,0,1).encode_bytes().hex()\n'15'\n>>> Vector[boolean,5](1,0,1,0,1).encode_bytes().hex()\n'0100010001'\n```\n\n### Bitlists\n\nBitlists in SSZ are similar to bitvectors but are designed to handle variable-length sequences of boolean values with a specified maximum length (`N`). \n\n**SSZ Serialization for Bitlists**\n\n```mermaid\nflowchart TD\n A[Start Serialization] --> B[Define Bitlist of Size N]\n B --> C[Pack Bits into Bytes]\n C --> D[Add Sentinel Bit]\n D --> E[Pad Final Byte if Necessary]\n E --> F[Output Serialized Byte Array]\n \n```\n\n_Figure: SSZ Serialization for Bitlists._\n\n\n**Define the Bitlist**: \n- A bitlist is defined by its maximum length `N`, which determines the upper bound of bits that can be included. The actual number of bits, however, can be less than `N`.\n\n**Pack Bits into Bytes**:\n- Each bit in the bitlist represents a boolean value, where `0` corresponds to `False` and `1` to `True`.\n- These bits are serialized into a byte array, packed from the LSB to the MSB within each byte, similar to bitvectors.\n\n**Add Sentinel Bit**:\n- To mark the end of the bitlist and distinguish its actual length from its maximum capacity, a sentinel bit (`1`) is added to the end of the bit sequence. This is crucial to ensure that the deserialization process accurately identifies the length of the bitlist.\n\n**Byte Array Formation and Padding**:\n- After including the sentinel bit, the bits are packed into bytes, with any necessary padding applied to the last byte to complete it if the total number of bits (including the sentinel) does not divide evenly by 8.\n\n\n**SSZ Deserialization for Bitlists**\n\n```mermaid\nflowchart TD\n A[Start Deserialization] --> B[Receive Serialized Byte Array]\n B --> C[Convert Bytes to Bits]\n C --> D[Identify and Remove Sentinel Bit]\n D --> E[Remove Padding Bits]\n E --> F[Reconstruct Original Bitlist]\n F --> G[Output Deserialized Bitlist]\n \n```\n\n_Figure: SSZ Deserialization for Bitlists._\n\n**Receive Serialized Byte Array**: \n- Start with the byte array that encodes the bitlist, including the sentinel bit.\n\n**Extract Bits from Bytes**:\n- Convert each byte back into bits, respecting the order (LSB to MSB).\n- Continue this process for each byte in the serialized data.\n\n**Identify and Remove the Sentinel Bit**:\n- As bits are extracted, locate the first `1` (sentinel bit) from the end of the bit sequence to determine the actual end of the bitlist data.\n- All bits following the sentinel bit are disregarded as padding.\n\n**Reconstruct the Bitlist**:\n- Reassemble the extracted bits (excluding the sentinel bit and any padding) into the original bitlist format.\n\nYou can run the encoding of Bitlist like below:\n\n```python\n>>> from eth2spec.utils.ssz.ssz_typing import Bitlist\n>>> Bitlist[100](0,0,0).encode_bytes().hex()\n'08'\n```\n\nAs a consequence of the sentinel, we require an extra byte to serialize a bitlist if its actual length is a multiple of eight (irrespective of the maximum length `N`). This is not the case for a bitvector.\n\n```python\n>>> Bitlist[8](0,0,0,0,0,0,0,0).encode_bytes().hex()\n'0001'\n>>> Bitvector[8](0,0,0,0,0,0,0,0).encode_bytes().hex()\n'00'\n```\n\n### Containers\n\nContainers in SSZ are fundamental structures used to group multiple fields into a single composite type. Each field within a container can be of any SSZ-supported type, including basic types like `uint64`, more complex types like other containers, vectors, or lists. Containers are analogous to structures or objects in programming languages, making them integral for representing complex and nested data structures in Ethereum.\n\n**SSZ Serialization for Containers**\n\n```mermaid\nflowchart TD\n A[Start Serialization] --> B[Define Container Schema]\n B --> C[Serialize Each Field According to Type]\n C --> D[\"Serialize Basic Types\\n (uint64, boolean, etc.)\"]\n C --> E[\"Serialize Composite Types\\n (Other containers, lists, vectors)\"]\n D --> F[Concatenate Serialized Outputs of Fields]\n E --> F\n F --> G[Output Serialized Container]\n \n```\n\n_Figure: SSZ Serialization for Containers._\n\n**Define the Container**: \n- A container in SSZ is defined by its schema, which specifies the types and order of its fields. This schema is crucial because it dictates how data should be serialized and deserialized.\n\n**Serialize Each Field**:\n- Each field in the container is serialized in the order defined by the schema.\n- The serialization method for each field depends on its type:\n- **Basic types** are converted directly to their byte representations.\n- **Composite types** (other containers, lists, vectors) are serialized recursively according to their own rules.\n\n**Concatenate Serialized Fields**:\n- The serialized outputs of all fields are concatenated to form the complete serialized data of the container.\n- If a field is of a variable size (like a list or a vector with variable length), its serialized data includes a length prefix or it may use offsets to indicate the start of the data, depending on the specifics of the implementation and type.\n\n**SSZ Deserialization for Containers**\n\n```mermaid\nflowchart TD\n A[Start Deserialization] --> B[Receive Serialized Container Data]\n B --> C[Parse Data According to \\nContainer Schema]\n C --> D[Deserialize Fields Based on Type]\n D --> E[Deserialize Basic Types]\n D --> F[Deserialize Composite Types]\n E --> G[Reconstruct Container with Deserialized Fields]\n F --> G\n G --> H[Output Deserialized Container]\n \n```\n\n_Figure: SSZ Deserialization for Containers._\n\n**Read Serialized Data**: \n- Begin with the serialized byte stream that represents the container.\n\n**Parse Serialized Data According to Schema**:\n- Based on the container's schema, parse the serialized data into its constituent fields.\n- This requires knowing the type and size of each field to correctly extract and deserialize each one.\n\n**Deserialize Each Field**:\n- Each field's data is deserialized according to its type.\n- Deserialization might involve converting byte arrays back into integers, decoding nested containers, or reconstructing lists and vectors from their serialized forms.\n\n**Reconstruct the Container**:\n- As each field is deserialized, reconstruct the container by placing each field back into its defined position.\n\n**Example**:\n\nLet's look into the SSZ serialization and deserialization process using the specific example of the `IndexedAttestation` container from the Beacon Chain. This example will outline how complex, nested containers are handled and processed in SSZ, particularly those involving both fixed-size and variable-size data types.\n\nThe `IndexedAttestation` container looks like this.\n\n```python\nclass IndexedAttestation(Container):\n attesting_indices: List[ValidatorIndex, MAX_VALIDATORS_PER_COMMITTEE]\n data: AttestationData\n signature: BLSSignature\n```\n\nIt contains an `AttestationData` container,\n\n```python\nclass AttestationData(Container):\n slot: Slot\n index: CommitteeIndex\n beacon_block_root: Root\n source: Checkpoint\n target: Checkpoint\n```\n\nwhich in turn contains two `Checkpoint` containers,\n\n```python\nclass Checkpoint(Container):\n epoch: Epoch\n root: Root\n``` \n\n**IndexedAttestation Container Structure**\n\nThe `IndexedAttestation` container includes several fields, some of which are fixed-size basic types and others are composite types including another container (`AttestationData`) and lists (like `attesting_indices`).\n\nHere's the structure:\n\n- **attesting_indices**: `List[ValidatorIndex, MAX_VALIDATORS_PER_COMMITTEE]` (variable size)\n- **data**: `AttestationData` (composite container)\n- **signature**: `BLSSignature` (fixed size)\n\n**AttestationData Container Structure**\n\n- **slot**: `Slot` (fixed size)\n- **index**: `CommitteeIndex` (fixed size)\n- **beacon_block_root**: `Root` (fixed size)\n- **source**: `Checkpoint` (composite container)\n- **target**: `Checkpoint` (composite container)\n\n**Checkpoint Container Structure**\n- **epoch**: `Epoch` (fixed size)\n- **root**: `Root` (fixed size)\n\n**Serialization Process**\n\n- **Serialize Fixed and Variable Components**\n - The serialization of an `IndexedAttestation` involves serializing each component based on its type:\n\n- **Serialize Fixed-Size Elements**\n - Each fixed-size element (`Slot`, `CommitteeIndex`, `Epoch`, `Root`, `BLSSignature`) is serialized to its corresponding byte format, typically little-endian for numeric types.\n\n- **Serialize Variable-Size Elements**\n - The `List[ValidatorIndex, MAX_VALIDATORS_PER_COMMITTEE]` is serialized by first recording the length of the list followed by the serialized form of each index.\n - If a list or another variable-size element is empty or not at maximum capacity, it only consumes the space necessary for the actual data present, plus possibly some length or offset metadata.\n\n- **Concatenate Serialized Data**\n - All serialized bytes are concatenated in the order specified by the container's structure. Fixed-size fields are directly placed in order, while variable-size fields might include offsets or lengths as part of the serialization.\n\n**Example Serialization Output**\n\n```python\nfrom eth2spec.utils.ssz.ssz_typing import *\nfrom eth2spec.capella import mainnet\nfrom eth2spec.capella.mainnet import *\n\nattestation = IndexedAttestation(\n attesting_indices = [33652, 59750, 92360],\n data = AttestationData(\n slot = 3080829,\n index = 9,\n beacon_block_root = '0x4f4250c05956f5c2b87129cf7372f14dd576fc152543bf7042e963196b843fe6',\n source = Checkpoint (\n epoch = 96274,\n root = '0xd24639f2e661bc1adcbe7157280776cf76670fff0fee0691f146ab827f4f1ade'\n ),\n target = Checkpoint(\n epoch = 96275,\n root = '0x9bcd31881817ddeab686f878c8619d664e8bfa4f8948707cba5bc25c8d74915d'\n )\n ),\n signature = '0xaaf504503ff15ae86723c906b4b6bac91ad728e4431aea3be2e8e3acc888d8af'\n + '5dffbbcf53b234ea8e3fde67fbb09120027335ec63cf23f0213cc439e8d1b856'\n + 'c2ddfc1a78ed3326fb9b4fe333af4ad3702159dbf9caeb1a4633b752991ac437'\n)\n\nprint(attestation.encode_bytes().hex())\n```\n\nThe resulting serialized blob of data that represents this `IndexedAttestation` object is (in hexadecimal):\n\n```code\ne40000007d022f000000000009000000000000004f4250c05956f5c2b87129cf7372f14dd576fc15\n2543bf7042e963196b843fe61278010000000000d24639f2e661bc1adcbe7157280776cf76670fff\n0fee0691f146ab827f4f1ade13780100000000009bcd31881817ddeab686f878c8619d664e8bfa4f\n8948707cba5bc25c8d74915daaf504503ff15ae86723c906b4b6bac91ad728e4431aea3be2e8e3ac\nc888d8af5dffbbcf53b234ea8e3fde67fbb09120027335ec63cf23f0213cc439e8d1b856c2ddfc1a\n78ed3326fb9b4fe333af4ad3702159dbf9caeb1a4633b752991ac437748300000000000066e90000\n00000000c868010000000000\n```\n\n**Breakdown of the Serialization Output**\n\nTo clearly explain the serialization process and the structure of the serialized data for the `IndexedAttestation` container in the example, let's break down the serialization into its individual components and understand how each part is represented in the byte stream. This unpacking helps illustrate how the SSZ format manages complex data structures.\n\n**Part 1: Fixed Size Elements**\n\n**4-byte Offset for Variable Size List (`attesting_indices`)**:\n- **Byte Offset**: `00`\n- **Value**: `e4000000`\n- **Explanation**: This indicates the start of the `attesting_indices` list in the serialized byte stream. The hexadecimal value `e4` converted to decimal is `228`, meaning the list starts at byte `228` from the beginning of the byte stream.\n\n**Slot (uint64)**:\n- **Byte Offset**: `04`\n- **Value**: `7d022f0000000000`\n- **Explanation**: Represents the `slot` field serialized as a 64-bit unsigned integer. The hexadecimal `7d022f00` in little-endian format translates to `3080829` in decimal, which is the slot number.\n\n**Committee Index (uint64)**:\n- **Byte Offset**: `0c`\n- **Value**: `0900000000000000`\n- **Explanation**: This is the `index` field, representing a committee index as a 64-bit unsigned integer. The value `09` indicates committee index `9`.\n\n**Beacon Block Root (Bytes32)**:\n- **Byte Offset**: `14`\n- **Value**: `4f4250c05956f5c2b87129cf7372f14dd576fc152543bf7042e963196b843fe6`\n- **Explanation**: This is a 256-bit hash stored as `Bytes32`, representing the root hash of the beacon block.\n\n**Source Checkpoint Epoch (uint64) and Root (Bytes32)**:\n- **Epoch Byte Offset**: `34`\n- **Epoch Value**: `1278010000000000`\n- **Root Byte Offset**: `3c`\n- **Root Value**: `d24639f2e661bc1adcbe7157280776cf76670fff0fee0691f146ab827f4f1ade`\n- **Explanation**: The source checkpoint contains an `epoch` (96274) and a `root`. The root is another 256-bit hash.\n\n**Target Checkpoint Epoch (uint64) and Root (Bytes32)**:\n- **Epoch Byte Offset**: `5c`\n- **Epoch Value**: `1378010000000000`\n- **Root Byte Offset**: `64`\n- **Root Value**: `9bcd31881817ddeab686f878c8619d664e8bfa4f8948707cba5bc25c8d74915d`\n- **Explanation**: Similar to the source, the target checkpoint includes an `epoch` (96275) and a `root`, detailing the intended target of the attestation.\n\n**Signature (BLSSignature/Bytes96)**:\n- **Byte Offset**: `84`\n- **Value**: Concatenated over several lines due to its length (96 bytes total).\n- **Explanation**: This is the cryptographic signature of the attestation, verifying its authenticity.\n\n**Part 2: Variable Size Elements**\n\n**Attesting Indices (List[uint64, MAX_VALIDATORS_PER_COMMITTEE])**:\n- **Byte Offset**: `e4`\n- **Value**: `748300000000000066e9000000000000c868010000000000`\n- **Explanation**: This represents the list of validator indices who are attesting to the block. It starts from the offset `228` and contains indices such as `33652`, `59750`, and `92360`.\n\n\n## Resources\n- [Simple serialize](https://ethereum.org/en/developers/docs/data-structures-and-encoding/ssz/)\n- [SSZ specs](https://github.com/ethereum/consensus-specs/blob/dev/ssz/simple-serialize.md)\n- [eth2book - SSZ](https://eth2book.info/capella/part2/building_blocks/ssz/#ssz-simple-serialize)\n- [Go Lessons from Writing a Serialization Library for Ethereum](https://rauljordan.com/go-lessons-from-writing-a-serialization-library-for-ethereum/)\n- [Interactive SSZ serializer/deserializer](https://www.ssz.dev/)\n- [SSZ encoding diagrams by Protolambda](https://github.com/protolambda/eth2-docs#ssz-encoding)\n- [SSZ explainer by Raul Jordan](https://rauljordan.com/go-lessons-from-writing-a-serialization-library-for-ethereum/)\n- [SSZ Specifications](https://github.com/ethereum/consensus-specs/blob/v1.3.0/ssz/simple-serialize.md)\n- [Why Ethereum Clients prefer SSZ over RLP?](https://etherworld.co/2023/01/25/why-ethereum-clients-prefer-ssz-over-rlp/)" }, { "path": "docs/wiki/CL/beacon-api.md", "content": "# Beacon Chain Spec and APIs\n\nAt the core of Ethereum Proof-of-Stake is a system chain called the \"Beacon Chain\". The beacon chain stores and manages the registry of validators. In the initial deployment phases of Proof-of-Stake, the only mechanism to become a validator is to make a one-way (withdrawable after Capella) ETH transaction to a deposit contract on the Ethereum proof-of-work chain. Activation as a validator happens when deposit receipts are processed by the Beacon Chain, the activation balance is reached, and a queuing process is completed. Exit is either voluntary or done forcibly as a penalty for misbehavior. The primary source of load on the beacon chain is \"attestations\". Attestations are simultaneously availability votes for a shard block (in a later upgrade) and proof-of-stake votes for a beacon block (Phase 0).\n\nThis section will cover some important parts of Beacon Chain Spec and APIs. Also checkout complete [Beacon Chain Spec](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/beacon-chain.md) and [Beacon API reference](https://ethereum.github.io/beacon-APIs/#/). \n\nBeacon API is the REST endpoint provided by consensus layer clients (beacon nodes). It's the interface to read information about the consensus and used by validator clients. \n\n## Containers\n\n`BeaconState`\n\n```python\nclass BeaconState(Container):\n # Versioning\n genesis_time: uint64\n genesis_validators_root: Root\n slot: Slot\n fork: Fork\n # History\n latest_block_header: BeaconBlockHeader\n block_roots: Vector[Root, SLOTS_PER_HISTORICAL_ROOT]\n state_roots: Vector[Root, SLOTS_PER_HISTORICAL_ROOT]\n historical_roots: List[Root, HISTORICAL_ROOTS_LIMIT]\n # Eth1\n eth1_data: Eth1Data\n eth1_data_votes: List[Eth1Data, EPOCHS_PER_ETH1_VOTING_PERIOD * SLOTS_PER_EPOCH]\n eth1_deposit_index: uint64\n # Registry\n validators: List[Validator, VALIDATOR_REGISTRY_LIMIT]\n balances: List[Gwei, VALIDATOR_REGISTRY_LIMIT]\n # Randomness\n randao_mixes: Vector[Bytes32, EPOCHS_PER_HISTORICAL_VECTOR]\n # Slashings\n slashings: Vector[Gwei, EPOCHS_PER_SLASHINGS_VECTOR] # Per-epoch sums of slashed effective balances\n # Participation\n previous_epoch_participation: List[ParticipationFlags, VALIDATOR_REGISTRY_LIMIT]\n current_epoch_participation: List[ParticipationFlags, VALIDATOR_REGISTRY_LIMIT]\n # Finality\n justification_bits: Bitvector[JUSTIFICATION_BITS_LENGTH] # Bit set for every recent justified epoch\n previous_justified_checkpoint: Checkpoint\n current_justified_checkpoint: Checkpoint\n finalized_checkpoint: Checkpoint\n # Inactivity\n inactivity_scores: List[uint64, VALIDATOR_REGISTRY_LIMIT]\n # Sync\n current_sync_committee: SyncCommittee\n next_sync_committee: SyncCommittee\n # Execution\n latest_execution_payload_header: ExecutionPayloadHeader\n # Withdrawals\n next_withdrawal_index: WithdrawalIndex\n next_withdrawal_validator_index: ValidatorIndex\n # Deep history valid from Capella onwards\n historical_summaries: List[HistoricalSummary, HISTORICAL_ROOTS_LIMIT]\n deposit_requests_start_index: uint64\n deposit_balance_to_consume: Gwei\n exit_balance_to_consume: Gwei\n earliest_exit_epoch: Epoch\n consolidation_balance_to_consume: Gwei\n earliest_consolidation_epoch: Epoch\n pending_deposits: List[PendingDeposit, PENDING_DEPOSITS_LIMIT]\n pending_partial_withdrawals: List[PendingPartialWithdrawal, PENDING_PARTIAL_WITHDRAWALS_LIMIT]\n pending_consolidations: List[PendingConsolidation, PENDING_CONSOLIDATIONS_LIMIT]\n```\n\n#### `BeaconBlockBody`\n\n```python\nclass BeaconBlockBody(Container):\n randao_reveal: BLSSignature\n eth1_data: Eth1Data # Eth1 data vote\n graffiti: Bytes32 # Arbitrary data\n # Operations\n proposer_slashings: List[ProposerSlashing, MAX_PROPOSER_SLASHINGS]\n attester_slashings: List[AttesterSlashing, MAX_ATTESTER_SLASHINGS_ELECTRA]\n attestations: List[Attestation, MAX_ATTESTATIONS_ELECTRA]\n deposits: List[Deposit, MAX_DEPOSITS]\n voluntary_exits: List[SignedVoluntaryExit, MAX_VOLUNTARY_EXITS]\n sync_aggregate: SyncAggregate\n # Execution\n execution_payload: ExecutionPayload\n bls_to_execution_changes: List[SignedBLSToExecutionChange, MAX_BLS_TO_EXECUTION_CHANGES]\n blob_kzg_commitments: List[KZGCommitment, MAX_BLOB_COMMITMENTS_PER_BLOCK]\n execution_requests: ExecutionRequests\n```\n" }, { "path": "docs/wiki/CL/cl-architecture.md", "content": "# Consensus Layer (CL) architecture\n\n> Many blockchain consensus protocols are _forkful_. Forkful chains use a fork choice rule, and sometimes undergo reorganisations.\n>\n> Ethereum's consensus protocol combines two separate consensus protocols. _LMD GHOST_ essentially provides liveness. _Casper FFG_ provides finality. Together they are known as _Gasper_.\n>\n> In a _live_ protocol, something good always happens. In a _safe_ protocol, nothing bad ever happens. No practical protocol can be always safe and always live.\n\n## Fork-choice Mechanism\n\nAs described in [BFT](/wiki/CL/overview.md?id=byzantine-fault-tolerance-bft-and-byzantine-generals39-problem), for various reasons - like network delays, outages, out-of-order messages, or malicious behavior — nodes in the network can have different views of the network's state. Eventually, we want every honest node to agree on an identical, linear history and a common view of the system's state. The protocol's fork choice rule is what helps achieve this agreement.\n\n#### Block Tree\nGiven a block tree and decision criteria based on a node's local view of the network, the fork choice rule is designed to select the branch that is most likely to become the final, linear, canonical chain. It chooses the branch least likely to be pruned out as nodes converge on a common view.\n\n\n\n
\n\n![Diagram for Block Tree](../../images/cl/blocktree.svg)\n\n
\n\n_The fork choice rule picks a head block from the candidates. The head block identifies a unique linear blockchain back to the Genesis block._\n\n
\n
\n\n#### Fork choice rules\n\nThe fork choice rule implicitly selects a branch by choosing a block at the branch's tip, called the head block. For any correct node, the first rule of any fork choice is that the chosen block must be valid according to protocol rules, and all its ancestors must also be valid. Any invalid block is ignored, and blocks built on an invalid block are also invalid.\n\nThere are several examples of different fork choice rules:\n\n- **Proof-of-work**: In Ethereum and Bitcoin, the \"heaviest chain rule\" (sometimes called \"longest chain\", though not strictly accurate) is used. The head block is the tip of the chain with the most cumulative \"work\" done.\n> Note that contrary to popular belief, Ethereum's Proof-of-work protocol [did not use](https://ethereum.stackexchange.com/questions/38121/why-did-ethereum-abandon-the-ghost-protocol/50693#50693) any form of GHOST in its fork choice. This misconception is very persistent, probably due to the [Ethereum Whitepaper](https://ethereum.org/en/whitepaper/#modified-ghost-implementation). Eventually when Vitalik was asked about it, he confirmed that although GHOST had been planned under PoW it was never implemented due to concerns about some unspecified attacks. The heaviest chain rule was simpler and well tested. It worked fine.\n- **Casper FFG (Proof-of-Stake)**: In Ethereum's PoS Casper FFG protocol, the fork-choice rule is to \"follow the chain containing the justified checkpoint of the **greatest height**\" and never revert a finalized block.\n- **LMD GHOST (Proof-of-Stake)**: In Ethereum's PoS LMD GHOST protocol, the fork-choice rule is to take the \"Greediest Heaviest Observed SubTree\". It involves counting accumulated votes from validators for blocks and their descendent blocks. It also applies the same rule as Casper FFG.\n\nEach of these fork choice rules assigns a numeric score to a block. The winning block, or head block, has the highest score. The goal is that all correct nodes, when they see a certain block, will agree that it is the head and follow its branch. This way, all correct nodes will eventually agree on a single canonical chain that goes back to Genesis.\n\n#### Reorgs and Reversion\n\nAs a node receives new votes (and new votes for blocks in Proof-of-stake), it re-evaluates the fork choice rule with this new information. Usually, a new block will be a child of the current head block, and it will become the new head block.\n\nSometimes, however, the new block might be a descendant of a different block in the block tree. If the node doesn't have the parent block of the new block, it will ask its peers for it and any other missing blocks.\n\nRunning the fork choice rule on the updated block tree might show that the new head block is on a different branch than the previous head block. When this happens, the node must perform a reorg (reorganisation). This means it will remove (revert) blocks it previously included and adopt the blocks on the new head's branch.\n\nFor example, if a node has blocks $A, B, D, E,$ and $F$ in its chain, and it views $F$ as the head block, it knows about block $C$ but it does not appear in its view of the chain; it is on a side branch.\n\n\n\n
\n\n![Diagram for Reorg-0](../../images/cl/reorg-0.svg)\n\n
\n\n_At this point, the node believes that block $F$ is the best head, therefore its chain is blocks $[A \\leftarrow B \\leftarrow D \\leftarrow E \\leftarrow F]$_\n\n
\n
\n\nWhen the node later receives block $G$, which is built on block $C$, not on its current head block $F$, it must decide if $G$ should be the new head. Just for example, If the fork choice rule says $G$ is the better head block, the node will revert blocks $D, E,$ and $F$. It will remove them from its chain, as if they were never received, and go back to the state after block $B$.\n\nThen, the node will add blocks $C$ and $G$ to its chain and process them. After this reorg, the node's chain will be $A, B, C,$ and $G$.\n\n\n\n
\n\n![Diagram for Reorg-1](../../images/cl/reorg-1.svg)\n\n
\n\n_Now the node believes that block $G$ is the best head, therefore its chain must change to the blocks $[A \\leftarrow B \\leftarrow C \\leftarrow G]$_\n\n
\n
\n\nLater, perhaps, a block $H$ might appear, that's built on $F$, and the fork choice rule says $H$ should be the new head, the node will reorg again, reverting to block $B$ and replaying blocks on $H$'s branch.\n\nShort reorgs of one or two blocks are common due to network delays. Longer reorgs should be rare unless the chain is under attack or there is a bug in the fork choice rule or its implementation.\n\n### Safety and Liveness\n\nIn consensus mechanisms, two key concepts are safety and liveness.\n\n**Safety** means \"nothing bad ever happens,\" such as preventing double-spending or finalizing conflicting checkpoints. It ensures consistency, meaning all honest nodes should always agree on the state of the blockchain.\n\n**Liveness** means \"something good eventually happens,\" ensuring the blockchain can always add new blocks and never gets stuck in a deadlock.\n\n**CAP Theorem** states that no distributed system can provide consistency, availability, and partition tolerance simultaneously. This means we can't design a system that is both safe and live under all circumstances when communication is unreliable.\n\n#### Ethereum Prioritizes Liveness\n\nEthereum’s consensus protocol aims to offer both safety and liveness in good network conditions. However, it prioritizes liveness during network issues. In a network partition, nodes on each side will continue to produce blocks but won't achieve finality (a safety property). If the partition persists, each side may finalize different histories, leading to two irreconcilable, independent chains.\n\nThus, while Ethereum strives for both safety and liveness, it leans towards ensuring the network remains live and continues to process transactions, even at the cost of potential safety issues during severe network disruptions.\n\n## The Ghosts in the Machine\n\nEthereum's Proof-of-Stake consensus protocol combines two separate protocols: [LMD GHOST](/wiki/CL/gasper?id=lmd-ghost.md) and [Casper FFG](/wiki/CL/gasper?id=casper-ffg.md). Together, they form the consensus protocol known as \"Gasper\". Detailed Information about both protocols and how they work in combination are covered in the next section [Gasper](/wiki/CL/gasper).\n\nGasper aims to combine the strengths of both LMD GHOST and Casper FFG. LMD GHOST provides liveness, ensuring the chain keeps running by producing new blocks regularly. However, it is prone to forks and not formally safe. Casper FFG, on the other hand, provides safety by periodically finalizing the chain, protecting it from long reversions.\n\nIn essence, LMD GHOST keeps the chain moving forward, while Casper FFG ensures stability by finalizing blocks. This combination allows Ethereum to prioritize liveness, meaning the chain continues to grow even if Casper FFG can't finalize blocks. Although this combined mechanism isn't always perfect and has some complexities, it is a practical engineering solution that works well in practice for Ethereum.\n\n## Architecture\n\nEthereum is a decentralized network of nodes that communicate via peer-to-peer connections. These connections are formed by computers running Ethereum's client software.\n\n
\n\n![Diagram for Network](../../images/cl/network.png)\n\n
\n\n_Nodes aren't required to run a validator client (green ones) to be a part of the network, however to take part in consensus one needs to stake 32 ETH and run a validator client._\n\n
\n
\n\n### Components of the Consensus Layer\n\n- **Beacon Node**: Beacon nodes use client software to coordinate Ethereum's proof-of-stake consensus. Examples include Prysm, Teku, Lighthouse, and Nimbus. Beacon nodes communicate with other beacon nodes, a local execution node, and optionally, a local validator.\n\n- **Validator**: Validator client is the software that allows people to stake 32 ETH in Ethereum's consensus layer. Validators propose blocks in the Proof-of-Stake system, which replaced Proof-of-work miners. Validators communicate only with a local beacon node, which instructs them and broadcasts their work to the network.\n\nThe main Ethereum network hosting real-world applications is called Ethereum Mainnet. Ethereum Mainnet is the live, production instance of Ethereum that mints and manages real Ethereum (ETH) and holds real monetary value.\n\nThere are also test networks that mint and manage test Ethereum for developers, node runners, and validators to test new functionality before using real ETH on Mainnet. Each Ethereum network has two layers: the execution layer (EL) and the consensus layer (CL). Every Ethereum node contains software for both layers: execution-layer client software (like Nethermind, Besu, Geth, and Erigon) and consensus-layer client software (like Prysm, Teku, Lighthouse, Nimbus, and Lodestar).\n\n\n\n
\n\n![Diagram for CL](../../images/cl/cl.png)\n\n
\n\n**Consensus Layer** is responsible for maintaining consensus chain (beacon chain) and processing the consensus blocks (beacon blocks) and attestations received from other peers. **Consensus clients** participate in a separate [peer-to-peer network](/wiki/CL/cl-networking.md) with a different specification from execution clients. They need to participate in block gossip to receive new blocks from peers and broadcast blocks when it's their turn to propose.\n\nBoth EL and CL clients run in parallel and need to be connected for communication. The consensus client provides instructions to the execution client, and the execution client passes transaction bundles to the consensus client to include in Beacon blocks. Communication is achieved using a local RPC connection via the **Engine-API**. They share an [ENR](/wiki/CL/cl-networking?id=enr-ethereum-node-records) with separate keys for each client (eth1 key and eth2 key).\n\n### Control Flow\n\n**When the consensus client is not the block producer:**\n1. Receives a block via the block gossip protocol.\n2. Pre-validates the block.\n3. Sends transactions in the block to the execution layer as an execution payload.\n4. Execution layer executes transactions and validates the block state.\n5. Execution layer sends validation data back to the consensus layer.\n6. Consensus layer adds the block to its blockchain and attests to it, broadcasting the attestation over the network.\n\n**When the consensus client is the block producer:**\n1. Receives notice of being the next block producer.\n2. Calls the create block method in the execution client.\n3. Execution layer accesses the transaction mempool.\n4. Execution client bundles transactions into a block, executes them, and generates a block hash.\n5. Consensus client adds transactions and block hash to the beacon block.\n6. Consensus client broadcasts the block over the block gossip protocol.\n7. Other clients validate the block and attest to it.\n8. Once attested by sufficient validators, the block is added to the head of the chain, justified, and finalized.\n\n\n### State Transitions\n\nThe state transition function is essential in blockchains. Each node maintains a state that reflects its view of the world.\n\nNodes update their state by applying blocks in order using a \"state transition function\". This function is \"pure\", meaning its output depends only on the input and has no side effects. Thus, if every node starts with the same state (Genesis state) and applies the same blocks, they all end up with the same state. If they don't, there's a consensus failure.\n\nIf $S$ is a beacon state and $B$ a beacon block, the state transition function $f$ is:\n\n$$S' \\equiv f(S, B)$$\n\nHere, $S$ is the pre-state and $S'$ is the post-state. The function $f$ is iterated with each new block to update the state.\n\n### Beacon Chain State Transitions\n\nUnlike the block-driven Proof-of-work, the beacon chain is slot-driven. State updates depend on slot progress, regardless of block presence.\n\nThe beacon chain's state transition function includes:\n\n1. **Per-slot transition**: $S' \\equiv f_s(S)$\n2. **Per-block transition**: $S' \\equiv f_b(S, B)$\n3. **Per-epoch transition**: $S' \\equiv f_e(S)$\n\nEach function updates the chain at specific times, as defined in the beacon chain specification.\n\n### Validity Conditions\n\nThe post-state from a pre-state and a signed block is `state_transition(state, signed_block)`. Transitions causing unhandled exceptions (e.g., failed asserts or out-of-range accesses) or uint64 overflows/underflows are invalid.\n\n### Beacon chain state transition function\n\nThe post-state corresponding to a pre-state `state` and a signed block `signed_block` is defined as `state_transition(state, signed_block)`. State transitions that trigger an unhandled exception (e.g. a failed `assert` or an out-of-range list access) are considered invalid. State transitions that cause a `uint64` overflow or underflow are also considered invalid.\n\n```python\ndef state_transition(state: BeaconState, signed_block: SignedBeaconBlock, validate_result: bool=True) -> None:\n block = signed_block.message\n # Process slots (including those with no blocks) since block\n process_slots(state, block.slot)\n # Verify signature\n if validate_result:\n assert verify_block_signature(state, signed_block)\n # Process block\n process_block(state, block)\n # Verify state root\n if validate_result:\n assert block.state_root == hash_tree_root(state)\n```\n\n```python\ndef verify_block_signature(state: BeaconState, signed_block: SignedBeaconBlock) -> bool:\n proposer = state.validators[signed_block.message.proposer_index]\n signing_root = compute_signing_root(signed_block.message, get_domain(state, DOMAIN_BEACON_PROPOSER))\n return bls.Verify(proposer.pubkey, signing_root, signed_block.signature)\n```\n\n```python\ndef process_slots(state: BeaconState, slot: Slot) -> None:\n assert state.slot < slot\n while state.slot < slot:\n process_slot(state)\n # Process epoch on the start slot of the next epoch\n if (state.slot + 1) % SLOTS_PER_EPOCH == 0:\n process_epoch(state)\n state.slot = Slot(state.slot + 1)\n```\n\n\n## Resources\n\n- Vitalik Buterin, [\"Parametrizing Casper: the decentralization/finality time/overhead tradeoff\"](https://medium.com/@VitalikButerin/parametrizing-casper-the-decentralization-finality-time-overhead-tradeoff-3f2011672735)\n- [Engine API spec](https://hackmd.io/@n0ble/consensus_api_design_space)\n- [Vitalik's Annotated Ethereum 2.0 Spec](https://notes.ethereum.org/@vbuterin/SkeyEI3xv)\n- Ethereum, [\"Eth2: Annotated Spec\"](https://github.com/ethereum/annotated-spec)\n- Martin Kleppmann, [Distributed Systems.](https://www.youtube.com/playlist?list=PLeKd45zvjcDFUEv_ohr_HdUFe97RItdiB)\n- Leslie Lamport et al., [The Byzantine Generals Problem.](https://lamport.azurewebsites.net/pubs/byz.pdf)\n- Austin Griffith, [Byzantine Generals - ETH.BUILD.](https://www.youtube.com/watch?v=c7yvOlwBPoQ)\n- Michael Sproul, [\"Inside Ethereum\"](https://www.youtube.com/watch?v=LviEOQD9e8c) \n- [Eth2 Handbook by Ben Edgington](https://eth2book.info/capella/part2/consensus/)\n- [Lighthouse Consensus Client architecture](https://www.youtube.com/watch?v=pLHhTh_vGZ0)\n" }, { "path": "docs/wiki/CL/cl-clients.md", "content": "# Consensus Client\n\n> **Consensus clients**, formerly known as *eth2 clients*, run Ethereum's proof-of-stake consensus algorithm allowing the network to reach agreement about the head of the Beacon Chain. Consensus clients do not participate in validating/broadcasting transactions or executing state transitions: that is done by execution clients. Consensus clients do not attest to, or propose new blocks: that is done by the validator client which is an optional add-on to the consensus client.\n\n## Overview Table\n\nThese clients are developed in different programming languages, provide have unique features and offer different performance profiles. All clients support Ethereum mainnet out of the box along with active testnets. Variety of implementations allows the network to benefit from client diversity. If you are choosing a client to use, current client diversity should be one of the main factors.\n\n| Client | Language | Developer | Status |\n| ----------------------------------------------------------------------- | ---------- | ------------------- | ----------- |\n| [Lighthouse](https://github.com/sigp/lighthouse) | Rust | Sigma Prime | Production |\n| [Lodestar](https://github.com/ChainSafe/lodestar) | TypeScript | ChainSafe | Production |\n| [Nimbus](https://github.com/status-im/nimbus-eth2) | Nim | Status | Production |\n| [Prysm](https://github.com/prysmaticlabs/prysm) | Go | Prysmatic Labs | Production |\n| [Teku](https://github.com/ConsenSys/teku) | Java | ConsenSys | Production |\n| [Grandine](https://github.com/grandinetech/grandine) | Rust | Grandine Developers | Production |\n| [Caplin](https://github.com/ledgerwatch/erigon) | Go | Erigon | Development |\n| [LambdaClass](https://github.com/lambdaclass/lambda_ethereum_consensus) | Elixir | LambdaClass | Development |\n\n\n## Distribution\n\nThe overwhelming majority of node operators are currently using either Prysm or Lighthouse as a Consensus Client.\nIn the interest of supporting the health of the Beacon Chain (formerly ETH2), it is recommended to use different clients.\n[Why?](https://clientdiversity.org/#why)\n\n\n### Lighthouse\nLighthouse, written in Rust by Sigma Prime, emphasizes security and performance. It's widely adopted but caution is advised as a supermajority could potentially lead to chain splits.\nLighthouse is licensed under Apache 2.0 and known for its robustness in production environments. \n\nLighthouse provides binaries for every platform including ARM and allows cross compilation. There are portable versions which are compromising compiler performance options for a better platform compatibility. Released binaries are signed by gpg key `15E66D941F697E28F49381F426416DC3F30674B0` from security@sigmaprime.io.\n\nNoteworthy Features:\n- [Cross compilation](https://lighthouse-book.sigmaprime.io/installation_cross_compiling.html)\n- [Slashing Protection](https://lighthouse-book.sigmaprime.io/validator_slashing_protection.html)\n- [Doppelganger Protection](https://lighthouse-book.sigmaprime.io/validator_doppelganger.html)\n- [Running a Slasher](https://lighthouse-book.sigmaprime.io/advanced_slasher.html)\n- [Block Proposer-only](https://lighthouse-book.sigmaprime.io/advanced_proposer_only.html)\n- [Prometheus and Grafana](https://lighthouse-book.sigmaprime.io/api_metrics.html)\n\n\n\n### Lodestar\nLodestar is a TypeScript-based Ethereum consensus client by ChainSafe, tailored for rapid prototyping and browser compatibility.\nIt supports beacon node and validator client functionalities, offering essential libraries like BLS and SSZ for Ethereum protocol development.\nLodestar is double-licensed under the Apache License 2.0 and the GNU Lesser General Public License (LGPL), allowing users to choose between a permissive and a copyleft licensing model.\n\nNoteworthy Features:\n- [Validator Client](https://chainsafe.github.io/lodestar/run/validator-management/vc-configuration)\n- [MEV and Builder Integration](https://chainsafe.github.io/lodestar/run/beacon-management/mev-and-builder-integration)\n- [Light Client](https://chainsafe.github.io/lodestar/libraries/lightclient-prover/lightclient)\n- [Prover](https://chainsafe.github.io/lodestar/libraries/lightclient-prover/prover)\n- [Prometheus and Grafana](https://chainsafe.github.io/lodestar/run/logging-and-metrics/prometheus-grafana)\n- [Remote Monitoring](https://chainsafe.github.io/lodestar/run/logging-and-metrics/client-monitoring)\n\n### Prysm\nPrysmatic Labs' Prysm client, written in Go, focuses on usability and reliability. It includes a full beacon node implementation and validator client, leveraging gRPC for interprocess communication, BoltDB for storage, and libp2p for networking. Prysm is designed for secure participation in Ethereum's proof-of-stake consensus.\n\nNoteworthy Features:\n- [Validator Client](https://docs.prylabs.network/docs/wallet/nondeterministic)\n- [Configuring MEV Builder](https://docs.prylabs.network/docs/advanced/builder)\n- [Running a Slasher](https://docs.prylabs.network/docs/prysm-usage/slasher)\n- [Prometheus and Grafana](https://docs.prylabs.network/docs/prysm-usage/monitoring/grafana-dashboard)\n- [Detailed Best Security Practices](https://docs.prylabs.network/docs/security-best-practices)\n\n### Nimbus\nNimbus, developed in Nim by Status, is optimized for resource efficiency. It supports lightweight devices like smartphones and Raspberry Pi's, conserving resources for other tasks when run on powerful servers. Nimbus features integrated validator client support, remote signing, performance analysis tools, and robust validator monitoring capabilities.\n\nNoteworthy Features:\n- [Run an Execution Client](https://nimbus.guide/eth1.html)\n- [Validator Client](https://nimbus.guide/validator-client.html)\n- [MEV and Builder Integration](https://nimbus.guide/external-block-builder.html)\n- [Prometheus and Grafana](https://nimbus.guide/metrics-pretty-pictures.html)\n\n### Teku\nConsenSys' Teku is a Java-based Ethereum consensus client offering comprehensive enterprise-grade features. It includes a full beacon node implementation, validator client, REST APIs for node management, Prometheus metrics for monitoring, and external key management for validator signing keys. Teku is suited for enterprise-level Ethereum deployments requiring scalability and operational control.\n\nNoteworthy Features:\n- [Validator Client](https://docs.teku.consensys.io/concepts/proof-of-stake)\n- [Slashing Protection](https://docs.teku.consensys.io/how-to/prevent-slashing/use-a-slashing-protection-file)\n- [Builder and MEV-boost](https://docs.teku.consensys.io/concepts/builder-network)\n- [Detect Doppelganger](https://docs.teku.consensys.io/how-to/prevent-slashing/detect-doppelgangers)\n- [Prometheus and Grafana](https://docs.teku.consensys.io/how-to/monitor/use-metrics)\n\n### Grandine\nGrandine is a fast and lightweight Ethereum consensus client designed with a focus on high performance and simplicity. It's written in Rust, same as Lighthouse and shares some of its libraries. \nDeveloped with parallelization and efficient resource utilization at its core, Grandine aims to push the boundaries of Ethereum's consensus layer by offering a streamlined alternative to existing clients.\nIts architecture is optimized to minimize latency and maximize throughput on high end machines, making it well-suited for environments where high performance is critical.\n\nNoteworthy Features:\n- [Validator Client](https://docs.grandine.io/validator_client.html)\n- [Slashing Protection](https://docs.grandine.io/slashing_protection.html)\n- [Builder and MEV](https://docs.grandine.io/builder_api_and_mev.html)\n- [Running a Slasher](https://github.com/grandinetech/grandine/tree/develop/slasher)\n- [Prometheus](https://docs.grandine.io/metrics.html) and [Grafana](https://github.com/grandinetech/grandine/tree/develop/metrics)\n\n### Caplin\n\nCaplin is a consensus client integrated within Erigon execution client. It's basically an extra feature in Erigon that allows to run it without any external CL. \n\n- https://erigon.gitbook.io/erigon/advanced-usage/consensus-layer/caplin\n- https://github.com/ledgerwatch/erigon/?tab=readme-ov-file#caplin\n\n### LambdaClass\n\nLambdaClass develops a client written in Elixir. It has been started during EPF4 and grew into fully featured implementation. It is still actively developed and not used in production.\n\n- https://github.com/lambdaclass/lambda_ethereum_consensus\n\n## Additional resources\n\n- [ETH Docker](https://eth-docker.net/)\n- [Ethernodes](https://ethernodes.org/)\n- [Client Diversity](https://clientdiversity.org/)\n- [Run the majority client at your own peril!](https://dankradfeist.de/ethereum/2022/03/24/run-the-majority-client-at-your-own-peril.html)\n- [Ethereum Hardware Resource Analysis](https://www.migalabs.io/blog/post/ethereum-hardware-resource-analysis-update)\n" }, { "path": "docs/wiki/CL/cl-networking.md", "content": "# Networking\n\nThe Consensus clients use [libp2p][libp2p-docs] as the peer-to-peer protocol, [libp2p-noise][libp2p-noise] for encryption, [discv5][discv5] for peer discovery, [SSZ][ssz] for encoding, and, optionally, [Snappy][snappy] for compression.\n\nFor those looking to deepen their understanding of libp2p, Study Group Session Week-5, [Lecture 19](https://epf.wiki/#/eps/day19) by Dapplion is a great resource.\n\n## Specs\n\nThe [Phase 0 -- Networking][consensus-networking] page specifies the network fundamentals, protocols, and rationale/design choices. The subsequent forks also specify the changes done in that respective fork.\n\n## libp2p - P2P protocol\n\n[libp2p][libp2p-docs] is a protocol for peer-to-peer communication, originally developed for [IPFS](https://ipfs.io). [libp2p and Ethereum][libp2p-and-eth] is a great article for a deep-dive on the history of libp2p, and its adoption in the Consensus layer. It allows communication over multiple transport protocols like TCP, QUIC, WebRTC, etc.\n\n
\n\n![libp2p_protocols](../../images/cl/cl-networking/libp2p-protocols.png)\n\n
\n\n_The various protocols which are a part of libp2p. Left: current Right: using QUIC_\n\n
\n
\n\nlibp2p protocol is a multi-transport stack.\n\n1. **Transport** : It must support TCP (Transmission Control Protocol), may support [QUIC][quic] (Quick UDP Internet Connections) which must both allow incoming and outgoing connections. TCP and QUIC both support IPv4 and IPv6, but due for better compatibility IPv4 support is required.\n2. **Encryption and Identification** : [libp2p-noise][libp2p-noise] secure channel is used for encryption and uses [multiaddress][multiaddr] (often abbreviated as multiaddr) is the convention for encoding multiple layers of addressing into a single \"future-proof\" path structure.\n\n- **Multiaddress**: Multiaddress defines a human-readable and machine-optimized encodings of common transport and overlay protocols and allows many layers of addressing to be combined and used together.
For example: the below given addressing format is a combination of \"location multiaddr\" (ip and port) and the identity multiaddr (libp2p peer id).\n\n
\n\n![multiaddr](../../images/cl/cl-networking/multiaddr.png)\n\n
\n\n_Multiaddr format_\n\n
\n
\n\n3. **Multiplexing** : Multiplexing allows multiple independent communications streams to run concurrently over a single network connection. Two multiplexers are commonplace in libp2p implementations: [mplex][mplex] and [yamux][yamux]. Their protocol IDs are, respectively: `/mplex/6.7.0` and `/yamux/1.0.0`. Clients must support mplex and may support yamux with precedence given to the latter.\n4. **Message Passing** : To pass messages over the network libp2p implements [Gossipsub][gossipsub] (PubSub) and [Req/Resp][req-resp] (Request/Response). Gossipsub uses topics and Req/Resp uses messages for communication.\n\n### **libp2p Protocol Stack**\n\n| **Layer** | **Protocol(s)** | **Purpose** |\n| ------------------------- | ------------------------------------------------------------------------------------- | ----------------------------------------------------------------------- |\n| 🧠 **Application Layer** | `pubsub`, `gossipsub`, `ping`, custom protocols | Run user-defined or built-in logic (chat, file transfer, pub-sub, etc.) |\n| 🔀 **Multiplexing Layer** | `yamux`, `mplex` | Allow multiple logical streams over a single connection |\n| 🔐 **Security Layer** | `noise`, `tls`, `secio` (deprecated) | Encrypt and authenticate peer connections |\n| 🔌 **Transport Layer** | `tcp`, `websockets`, `quic` (has multiplexing and security), `webrtc`, `webtransport` | Handle physical or virtual data transfer between machines |\n| 🌍 **NAT/Relay Layer** | `relay`, `dcutr`, `autonat`, `pnet` | Enable connectivity through NAT/firewalls or in private networks |\n| 📡 **Discovery Layer** | `mdns`, `kademlia`, `rendezvous`, `identify` | Find and learn about peers on the network |\n\n### Notes:\n\n- **Not all protocols are required** — libp2p is modular and you can choose only what you need.\n- A minimal connection includes at least: `transport` + `security` + `multiplexing` + `application protocol`.\n- `relay` and `dcutr` are used when NATs prevent direct connections.\n\nKey features of libp2p:\n\n1. **Protocol IDs:** are unique string identifiers used for protocol negotiation. Their basic structure is: `/app/protocol/version`. Some common protocols, all use protobuf to define message schemes, defined are:\n\n- Ping: `/ipfs/ping/1.0.0` is a simple protocol to test the connectivity and performance of connected peers\n- Identify : `/ipfs/id/1.0.0` allows to peers to exchange information about each other, mainly public key and know network addresses. Uses the following protobuf properties:\n | Field | Type | Purpose |\n |-------------------|-----------|-------------------------------------------------------------------------|\n | `protocolVersion` | `string` | libp2p protocol version (e.g., `ipfs/1.0.0`) |\n | `agentVersion` | `string` | Client info (like browser's user-agent, e.g., `go-ipfs/0.1.0`) |\n | `publicKey` | `bytes` | Node's public key (for identity, optional if secure channel is used) |\n | `listenAddrs` | `bytes[]` | Multiaddrs where the peer is listening |\n | `observedAddr` | `bytes` | Your IP address as seen by the peer (helps with NAT detection) |\n | `protocols` | `string[]`| List of supported application protocols (e.g., `/chat/1.0.0`) |\n | `signedPeerRecord`| `bytes` | Authenticated version of `listenAddrs` for sharing with other peers |\n\n- Identify/push: `/ipfs/id/push/1.0.0` same as \"Identify\" just that this is sent proactively and not in response to a request. It is useful to push a new address to its connected peers.\n\n**kad-dht** : libp2p uses Distributed Hash Table (DHT) based on the [Kademlia][kademlia] routing algorithm for its routing functionality.\n\n2. **Handler Functions:** are invoked during a incoming stream\n3. **Bi-Directional Binary Stream:** the medium over which the libp2p protocol transpires\n\n### **Peers**\n\n#### Peer Ids\n\n[Peer Identity][peer-identity] is a unique reference to specific peer in the network and remain constant as long as the peer lives. Peer Ids are [multihashes][multihash], which are a self-describing values having the following format:
\n\n``\n\n
\n\n![multihash_format](https://raw.githubusercontent.com/multiformats/multihash/master/img/multihash.006.jpg)\n\n
\n\n_Multihash Format , in hex_\n\n
\n
\n\n- Keys are encoded in a protobuf containing key type and encoded key. There are 4 specified methods for encoding: RSA, Ed255199v(must), Secp256k1, ECDSA.\n- There are 2 ways of the string representation of peer IDs in text: `base58btc` (starts with `QM` or `1`) and as a multibase encoded CID with libp2p slowly moving to the later.\n\n### **How a connection is established?**\n\nTo understand how setting up a connection works, read this [specs][libp2p-connection].\n\n
\n\n![flowchart of setting up a connection](../../images/cl/cl-networking/libp2p-connection.png)\n\n
\n\n_flowchart of setting up a connection_\n\n
\n
\n\n1. **Discovery**: How to find another peer?\n\n- `mdns` (Multicast DNS) : discover peers on the same local network with zero configuration, very simple. Send query for all peers, receive response and other peers' information into local database.\n- `rendezvous` : peers register themselves at a shared common peer or server (rendezvous point) and others query the same point to get peer information\n- `kademlia` (DHT) : A distributed hash table for global discovery. Peer query the DHT with peer ID to get its latest multiaddrs.\n- `identify` : protocol that allows peers to exchange metadata (addresses, protocols supported, version etc) after connecting\n\nResult: We now have a list of peers identifiable with Peer ID and reachable via multiaddrs (IP + port + protocol stack)\n\n2. **Transport** : How to connect to peers?\n\n- `TCP` : most basic transport, reliable but may be blocked by NAT/firewalls\n- `WebSockets` : TCP over HTTP, are NAT/firewall friendly\n- `QUIC` : UDP based, faster connection setup, supports multiplexing and encryption (TLS 1.3) natively\n- `WebRTC` : enable two private nodes (e.g. two browsers) to establish a direct connection\n- `WebTransport` : establish a stream-multiplexed and bidirectional connection to servers, run on top of a HTTP/3 connection with a fallback using HTTP/2\n\nIf the peer is behind NAT (when direct connection fails):\n\n- `relay` : it is like TURN , routes through another peer\n- `dcutr` (Direct Connection Upgrade Through Relay) : used to try and replace a relay connection with a direct one, using [hole punching][hole-punching]. It involves simultaneous dial attempts from both peers.\n\n3. **Encryption** : How to make the connection private and authenticated?\n\n- `noise` : framework for building security protocols, fast, default choice for many, Noise XX handshake for mutual authentication.\n- `tls` (Transport Layer Security) : strong security guarantees, mutual authentication done using peer's key\n- `secio` : deprecated due to complexity and lower assurance compared to Noise/TLS.\n\n4. **Multiplexing** : How to open multiple logical streams over the same connection?\n\n- `yamux` : Simple, fast, and currently the default in many implementations.\n- `mplex` : lightweight and older\n\n5. **Application** : run application protocols over the above setup\n\n- `ping` : basic liveliness check ,measure round-trip time\n- `pubsub`, `gossipsub`, `episub` : for broadcasting messages\n- Custom protocols that the implementation defines\n\n### What optimization does GossipSub provide?\n\n**Approach 1:** Maintain a fully connected mesh (all peers connected to each other 1:1), which scales poorly (O(n^2)). Why this scales poorly? Each node may receive the same message from other (n-1) nodes , hence wasting a lot of bandwidth. If the message is a block data, then the wasted bandwidth is exponentially large.\n\n**Approach 2:** Pubsub (Publish-Subscribe Model) messaging pattern is used where senders (publishers) don’t send messages directly to receivers (subscribers). Instead, messages are published to a common channel (or topic), and subscribers receive messages from that channel without direct interaction with the publisher. The nodes mesh with a particular number of other nodes for a topic, and those with other nodes. Hence, allowing more efficient message passing.\n\n
\n\n![gossipsub_optimization](../../images/cl/cl-networking/gossipsub_optimization.png)\n\n
\n\n_Gossipsub Optimization_\n\n
\n
\n\n###### **Gossipsub : TODO**\n\n###### **Req/Resp : TODO**\n\n###### **QUIC : TODO**\n\n## libp2p-noise - Encryption\n\nThe [Noise framework][noise-framework] is not a protocol itself, but a framework for designing key exchange protocols. The [specification][noise-specification] is a great place to start.\n\nThere are many [patterns][noise-patterns] which describe the key exchange process. The pattern used in the consensus clients is [`XX`][noise-xx] (transmit-transmit), meaning that both the initiator, and responder transmit their public key in the initial stages of the key exchange.\n\n## ENR (Ethereum Node Records)\n\n[Ethereum Node Records][ENR] provide a structured, flexible way to store and share node identity and connectivity details in Ethereum’s peer-to-peer network. It is a future-proof format that allows easier exchange of identifying information between new peers and is the preferred [network address format][network-add-format] for Ethereum nodes.\n\nIts core components are:\n\n1. **Signature**: Each record is signed using an identity scheme (e.g., secp256k1) to ensure authenticity.\n2. **Sequence Number** (seq): A 64-bit unsigned integer that increments whenever the record is updated, allowing peers to determine the latest version.\n3. **Key/Value Pairs**: The record holds various connectivity details as key-value pairs.\n\nIn its text form, the RLP of ENR is encoded in base64 and can be shared across clients as a string, e.g.:\n`\nenr:-Jq4QOXd31zNJBTBAT0ZZIRWH4z_NmRhnmAFfwNan0zr_-IUUAsOTbU_Lhzh4BSq8UknFGvr1rXQUYK0P-_ZUVenXkABhGV0aDKQaGGQMVAAEBv__________4JpZIJ2NIJpcIRBbZouiXNlY3AyNTZrMaEDxEArICqVUZNxhUxBYHZjzsm4KxqraeSION3yYorLZSuDdWRwgiMp\n`\n## discv5\n\nDiscovery Version 5 [(discv5)][discv5] (Protocol version v5.1) is a UDP-based node discovery protocol. At a protocol level, it is a Kademlia-inspired DHT that stores and relays signed Ethereum Node Records (ENRs) rather than arbitrary key-value pairs. Each node organizes other nodes by XOR distance between node IDs in a routing table of k-buckets, letting it keep track of nearby peers in the address space and progressively improve its view of the network.\n\nPeer discovery in discv5 happens through iterative lookups. A node starts with the closest peers it already knows, sends `FINDNODE` queries, receives `NODES` responses, and continues querying closer results until the lookup converges on the nearest reachable nodes for a target. This same lookup machinery underpins network sampling, service discovery, and ENR resolution. Unlike libp2p, which is responsible for maintaining peer connections and carrying protocol traffic, discv5 focuses on maintaining a searchable discovery index of live nodes and their advertised capabilities.\n\nIts three core functions are:\n\n- Sampling the set of all live participants by walking the discovery DHT and refreshing the local routing table over time\n- Searching for participants providing a certain service through topic advertisements and lookups around the topic hash\n- Authoritative resolution of node records by retrieving the latest ENR for a known node ID and comparing ENR sequence numbers\n\nIn Ethereum consensus clients, discv5 typically runs alongside libp2p, which handles peer connections and protocol traffic.\n\n
\n\n![discv5](../../images/cl/cl-networking/discv5.png)\n\n
\n\n_discv5_\n\n
\n
\n\n### Lookup flow\n\nA discv5 lookup is an iterative search over node ID space, not a broadcast to the whole network. The initiator repeatedly asks nodes that are already close to the target for even closer nodes, which gives Kademlia its logarithmic scaling properties and lets the discovery table improve as a side effect of normal operation.\n\n1. A node selects the closest known peers to a target node ID from its local routing table.\n2. It sends `FINDNODE` requests to a small concurrent set of those peers.\n3. Responding peers return `NODES` messages containing ENRs near the queried distance.\n4. The initiator merges the returned ENRs into its local view, sorts them by XOR distance to the target, and continues querying closer candidates.\n5. The lookup converges once the node has queried the closest reachable candidates it has learned about.\n\nThis same pattern is reused for multiple tasks. Random targets let a node walk the DHT and sample live participants. A known node ID lets the caller resolve the freshest ENR for that node. Topic-based discovery reuses Kademlia lookups around the hash of a topic so nodes can find peers advertising a specific service.\n\n### discv5 and libp2p\n\nIn consensus clients, discv5 and libp2p solve adjacent but different problems. discv5 is the discovery plane: it maintains a searchable index of signed node records, verifies liveness, and helps nodes learn who exists and how to reach them. libp2p is the transport and messaging plane: once useful peers are known, the client dials them through libp2p and then exchanges beacon-chain traffic over gossip and request/response protocols.\n\nThis separation matters because discovery and transport have different constraints. discv5 uses UDP and an encrypted handshake optimized for many short interactions with a large set of remote nodes. libp2p, by contrast, maintains longer-lived authenticated connections and carries the actual application protocols such as gossipsub, ping, and req/resp. In practice, discv5 answers \"which peers should I try next?\" while libp2p answers \"how do I maintain a session with them and exchange protocol messages?\"\n\n### Security and handshake\n\ndiscv5 does not send discovery traffic as plain unauthenticated UDP. Ordinary packets are encrypted and authenticated, and when a node cannot decrypt a message from an endpoint it answers with a `WHOAREYOU` challenge instead of blindly returning discovery data. This forces the initiator to prove control of its node identity and establish fresh session keys before the recipient accepts requests such as `FINDNODE`.\n\nAt a high level, the exchange works as follows:\n\n1. Node A sends an ordinary request, for example `FINDNODE`, to node B.\n2. If node B has no valid session for that endpoint, it replies with `WHOAREYOU`, carrying a nonce and the ENR sequence number it currently knows for A.\n3. Node A re-sends the request as a handshake packet, including an identity signature, an ephemeral public key, and its ENR when B needs a newer copy.\n4. Both sides derive session keys, authenticate the packet, and continue with encrypted request/response messages.\n\nThis handshake serves several purposes at once. It reduces amplification risk because an unknown sender first receives only a small challenge packet. It ties session state to a specific node ID and UDP endpoint, which makes spoofing and cross-endpoint replay harder. It also gives nodes a built-in path for ENR synchronization: when the recipient advertises an older `enr-seq`, the sender can attach its newer record during the handshake or later refresh it through `PING`/`PONG` and explicit ENR retrieval.\n\nUDP is still a deliberate choice even with this cryptographic machinery. Discovery traffic consists of many short-lived interactions with many remote nodes, frequent table refreshes, and repeated liveness checks. Using UDP keeps those exchanges lightweight and avoids the connection-management overhead of establishing full transport sessions just to ask a few discovery questions. The tradeoff is that packets may be lost or arrive out of order, so discv5 is designed around short timeouts, retry through new lookups, and a routing table that is continuously refreshed rather than assumed to be perfect at any single moment.\n\n## SSZ - Encoding\n\n[Simple serialize (SSZ)][ssz] replaces the [RLP][rlp] serialization used on the execution layer everywhere across the consensus layer except the peer discovery protocol. SSZ is designed to be deterministic and also to Merkleize efficiently. SSZ can be thought of as having two components: a serialization scheme and a Merkleization scheme that is designed to work efficiently with the serialized data structure.\n\n## Snappy - Compression\n\n[Snappy][snappy] is a compression scheme created by engineers at Google in 2011. Its main design considerations prioritize compression/decompression speed, while still having a reasonable compression ratio.\n\n## Related R&D\n\n- [EIP-7594][peerdas-eip] - Peer Data Availability Sampling (PeerDAS)\n\n A networking protocol that allows beacon nodes to perform data availability\n sampling (DAS) to ensure that blob data has been made available while\n downloading only a subset of the data.\n\n - [Consensus Specs][peerdas-specs]\n - [ETH Research][peerdas-ethresearch]\n\n## Resources\n\n- [ENR rust docs][enr-rust-docs]\n- [Eth1+Eth2 client relationship][eth1+2-client]\n- Libp2p, [\"docs\"][libp2p-docs] and [\"specs\"][libp2p-specs]\n- Technical Report, [\"Gossipsub-v1.1 Evaluation Report\"][gossipsub-report]\n- [Libp2p resource][PLN-launchpad]\n- [Libp2p tutorial][libp2p-tutorial]\n- [Hole Punching][hole-punching]\n\n[consensus-networking]: https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md\n[libp2p-and-eth]: https://blog.libp2p.io/libp2p-and-ethereum/\n[libp2p-noise]: https://github.com/libp2p/specs/tree/master/noise\n[libp2p-docs]: https://docs.libp2p.io/\n[libp2p-specs]: https://github.com/libp2p/specs\n[noise-framework]: https://noiseprotocol.org/\n[noise-patterns]: https://noiseexplorer.com/patterns/\n[noise-specification]: https://noiseprotocol.org/noise.html\n[noise-xx]: https://noiseexplorer.com/patterns/XX/\n[discv5]: https://github.com/ethereum/devp2p/blob/master/discv5/discv5.md\n[peerdas-eip]: https://github.com/ethereum/EIPs/pull/8105\n[peerdas-ethresearch]: https://ethresear.ch/t/peerdas-a-simpler-das-approach-using-battle-tested-p2p-components/16541\n[peerdas-specs]: https://github.com/ethereum/consensus-specs/pull/3574\n[rlp]: https://ethereum.org/developers/docs/data-structures-and-encoding/rlp\n[snappy]: https://en.wikipedia.org/wiki/Snappy_(compression)\n[ssz]: https://ethereum.org/developers/docs/data-structures-and-encoding/ssz\n[blog]: https://medium.com/coinmonks/dissecting-the-ethereum-networking-stack-node-discovery-4b3f7895f83f\n[enr-rust-docs]: https://docs.rs/enr/latest/enr\n[eth1+2-client]: https://ethresear.ch/t/eth1-eth2-client-relationship/7248\n[gossipsub-report]: https://research.protocol.ai/publications/gossipsub-v1.1-evaluation-report/vyzovitis2020.pdf\n[ENR]: https://eips.ethereum.org/EIPS/eip-778\n[network-add-format]: https://dean.eigenmann.me/blog/2020/01/21/network-addresses-in-ethereum/\n[quic]: https://datatracker.ietf.org/doc/rfc9000/\n[yamux]: https://github.com/libp2p/specs/blob/master/yamux/README.md\n[mplex]: https://github.com/libp2p/specs/tree/master/mplex\n[gossipsub]: https://github.com/libp2p/specs/tree/master/pubsub/gossipsub\n[req-resp]: https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#the-reqresp-domain\n[multiaddr]: https://github.com/libp2p/specs/blob/master/addressing/README.md\n[PLN-launchpad]: https://pl-launchpad.io/curriculum/libp2p/objectives/\n[kademlia]: https://docs.ipfs.tech/concepts/dht/#kademlia\n[libp2p-tutorial]: https://proto.school/introduction-to-libp2p\n[multihash]: https://github.com/multiformats/multihash?tab=readme-ov-file\n[multistream-select]: https://github.com/multiformats/multistream-select\n[libp2p-connection]: https://github.com/libp2p/specs/blob/master/connections/README.md\n[hole-punching]: https://github.com/libp2p/specs/blob/master/connections/hole-punching.md\n[peer-identity]: https://github.com/libp2p/specs/blob/master/peer-ids/peer-ids.md\n[hole-punching]: https://blog.ipfs.tech/2022-01-20-libp2p-hole-punching/\n" }, { "path": "docs/wiki/CL/cl-specs.md", "content": "# Consensus layer specification \n\n> :warning: This article is a [stub](https://en.wikipedia.org/wiki/Wikipedia:Stub), help the wiki by [contributing](/contributing.md) and expanding it.\n\nEthereum network started as a proof-of-work blockchain with the intention of switching to proof-of-stake after its bootstrap. The research produced a consensus mechanism combining Casper and GHOST, released in [Gasper paper](https://arxiv.org/abs/2003.03052).\n\nBased on its design, a specification was written in python. [Pyspec](https://github.com/ethereum/consensus-specs) is an executable specification that serves as a reference for consensus layer developers. It is also used as reference for client implementations and for creating the test case vectors for clients.\n\n## Resource\n\n[How to use Executable Consensus Pyspec by Hsiao-Wei Wang | Devcon Bogotá](https://www.youtube.com/watch?v=ZDUfYJkTeYw)" }, { "path": "docs/wiki/CL/gasper.md", "content": "# Gasper\n\n## LMD GHOST (Latest Message Driven -- Greediest Heaviest Observed SubTree)\n\n\n\n## Casper FFG (Friendly Finality Gadget)\n\n\n\n\n- Hybrid Fork-choice (Refer pos-evolution in ethereum post/book)\nPossible attacks\n- simple ex-ante reorg\n- weighted proposer boost\n\nSolutions: \n- view-merge strategy\n\n\n## Resources\n\n- [Combining GHOST and Casper](https://arxiv.org/pdf/2003.03052)\n- [Yang X Zhang- Combining GHOST and Casper](https://www.youtube.com/watch?v=V0RjGmFE35U)\n- [Introduction to Gasper from Ethereum.org](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/gasper/)\n- [Evolution of Ethereum PoS Consensus Protocol](https://github.com/ethereum/pos-evolution/blob/master/pos-evolution.md)\n- [Goldfish](https://arxiv.org/pdf/2209.03255)\n- [Casper FFG](https://arxiv.org/pdf/1710.09437)\n- [LMD Ghost](https://inevitableeth.com/home/ethereum/network/consensus/lmd-ghost)\n- [RLMD GHOST with Luca Zanolini](https://www.youtube.com/watch?v=F2olypDSVnA)\n- [Comparison of different LMD Ghost Implementations by ProtoLambda](https://github.com/protolambda/lmd-ghost)" }, { "path": "docs/wiki/CL/merkleization.md", "content": "# Merkleization and Hash Tree Roots \n\n\nIn Ethereum consensus mechanism, it's critical for all participating nodes to agree on the state of the system consistently and efficiently. The [Simple Serialize (SSZ)](/wiki/CL/SSZ.md) framework facilitates this through Merkleization, a process that transforms serialized data into a Merkle tree structure. The goal of the Merkleization scheme is to ensure that constrained environments (light clients, execution environments, etc.) can have access to light-weight proofs which they can use to make important decisions. This wiki page discusses the intricacies of Merkleization and its importance in ensuring a shared state across nodes in a scalable and secure manner.\n\n\n## Terminology and Methods\n\n- **Merkleization:** Refers to constructing a Merkle tree and deriving its root.\n- **Hash Tree Root:** A specific application of Merkleization, used to compute the root hash of complex SSZ container.\n\n## The Need for Merkleization\n\nCryptographic hash functions provide a solution by generating a compact, unique representation of a data set for a Beacon state. By hashing the serialized state of a Beacon chain, nodes can quickly and efficiently compare states by exchanging these small hash outputs.\n\n## Process of Merkleization\n\nMerkleization involves breaking down the serialized data into 32-byte chunks, which serve as the leaves of a Merkle tree. These chunks are then combined pair-wise, hashed together, and the process is repeated up the tree until a single hash—the Merkle root—is derived. This root hash acts as a unique fingerprint for the entire dataset. The key steps are as below:\n\n- **Chunking:** Divide the serialized data into 32-byte chunks.\n- **Tree Construction:** Pair up the chunks and hash each pair to form the next level of the tree. Repeat this step until only one hash remains: the Merkle root.\n- **Padding:** If the number of chunks isn't a power of two, additional zero-value chunks are added to round out the tree, ensuring that the tree is balanced.\n\n## Benefits of Merkleization\n\n- **Performance Efficiency:** While the tree requires hashing approximately twice the original data amount, caching mechanisms can store the roots of subtrees that don't change often. This significantly reduces the computational overhead as only altered parts of the data need re-hashing.\n- **Light Client Support:** The Merkle tree structure supports the creation of Merkle proofs—small pieces of data that prove the inclusion and integrity of specific parts of the state without needing the entire dataset. This feature is crucial for light clients, which operate with limited resources and rely on these proofs to interact with Ethereum securely.\n\nIf you want to learn more about the Merkle tree structure, you can refer [here](https://eth2book.info/capella/part2/building_blocks/merkleization/) and [here](https://github.com/protolambda/eth2-docs?tab=readme-ov-file#ssz-hash-tree-root-and-merkleization). \n\n## Generalized Indices\n\nTo facilitate direct referencing and verification within the tree, each node (both leaves and internals) is assigned a generalized index. This index is derived from the node’s position within the tree:\n\n```mermaid\ngraph TD;\n 1((1 / Depth 0))\n 2((2 / Depth 1))\n 3((3 / Depth 1))\n 4((4 / Depth 2))\n 5((5 / Depth 2))\n 6((6 / Depth 2))\n 7((7 / Depth 2))\n\n 1 --> 2\n 1 --> 3\n 2 --> 4\n 2 --> 5\n 3 --> 6\n 3 --> 7\n```\n\n_Figure: Merkle Tree Generalized Indices and Depth Levels._\n\n- **Root Index:** 1 (depth = 0)\n- **Subsequent Levels:** $2^{depth} + index$ where index is the node's zero-indexed position at that depth.\n\n## Multiproofs Using Generalized Indices\n\nMultiproofs using generalized indices provide an efficient way to verify specific elements within a Merkle tree without needing to know the entire tree structure. This concept is crucial in Ethereum and cryptographic applications where data integrity and verification speed are paramount. Let's break down the process using an example to understand how multiproofs work:\n\n**Understanding the Structure**\n- A Merkle tree is structured in layers, where each node is either a leaf node (containing actual data) or an internal node (containing hashes of its child nodes).\n- Generalized indices numerically represent the position of each node in the tree, calculated as $2^{depth} + index$, starting from the root (index 1).\n\n**Tree Layout for the Example**\n- The tree is structured as follows, with `*` indicating the nodes required to generate the proof for the element at index 9:\n\n```mermaid\ngraph TD;\n 1((\"1*\"))---2((\"2\"));\n 1---3((\"3*\"));\n 2---4((\"4\"));\n 2---5((\"5*\"));\n 3---6((\"6\"));\n 3---7((\"7\"));\n 4---8((\"8*\"));\n 4---9((\"9*\"));\n 5---10((\"10\"));\n 5---11((\"11\"));\n 6---12((\"12\"));\n 6---13((\"13\"));\n 7---14((\"14\"));\n 7---15((\"15\"));\n\n```\n\n_Figure: Merkle Tree Layout_\n\n**Determining Required Nodes**\n- **Identifying Required Hashes**: To validate the data at index 9, you need the hashes of the data at indices 8, 9, 5, 3, and 1.\n- **Pairwise Hashing**: Combine the hashes of indices 8 and 9 to compute the hash corresponding to their parent node, which should be `hash(4)`.\n- **Further Hash Combinations**:\n - `hash(4)` is then combined with the hash from index 5 to produce the hash of their parent node, `hash(2)`.\n - This result is combined with the hash from index 3 to work up to the next level.\n- **Final Verification**: The combined result from the previous step is hashed with the root from the opposite branch (index 3) to produce the ultimate tree root (`hash 1`).\n- **Integrity Check**: If the calculated root matches the known good root (`hash 1`), the data at index 9 is verified as accurate. If the data was incorrect, the resulting root would differ, indicating an error or tampering.\n\nThere are helper functions in the consensus specs to calculate the multiproofs and generalized indices. You can find [here.](https://github.com/ethereum/consensus-specs/blob/dev/ssz/merkle-proofs.md#merkle-multiproofs)\n\n## Calculating Hash Tree Roots\n\nThe hash tree root of an SSZ object is computed recursively. For basic types and collections of basic types, the data is packed into chunks and directly Merkleized. For composite types like containers, the process involves hashing the tree roots of each component. In the below sections we will see the working examples to understand the process.\n\n### Packing and Chunking\n\nPacking and chunking enable the Merkleization with SSZ by formatting the serialized data and dividing them into pieces which are then hashed to a Merkle tree. Here's how the process works:\n\n**Serializing the Data**\n- **Serialization** involves converting a data structure (basic types, lists, vectors, or bitlists/bitvectors) into a linear byte array using SSZ serialization rules.\n- Each element is serialized based on its type. \n\n**Padding the Serialization**\n- After serialization, the byte array might not perfectly align with the 32-byte chunk size used in Merkle trees.\n- **Padding** is added to the serialized data to extend the last segment to a full 32-byte chunk. This padding consists of zero bytes (0x00).\n\n**Dividing into Chunks**\n- The padded serialized data is then split into multiple 32-byte segments or \"chunks.\"\n- These chunks are the basic units used in the Merkleization process.\n\n**Padding to Full Binary Tree**\n- The number of chunks from the previous step may not be a power of two, which is required to form a balanced binary tree (full binary tree).\n- Additional zero chunks (chunks filled entirely with zero bytes) are added as necessary to bring the total count up to the nearest power of two.\n- This ensures that the resulting Merkle tree is complete and balanced, facilitating efficient cryptographic operations.\n\n**Applying the Merkleization Process**\n- With the chunks prepared, they are arranged as the leaves of a binary Merkle tree.\n- Merkleization proceeds by hashing pairs of chunks together, layer by layer, until a single hash remains. This final hash is known as the Merkle root.\n\n**Practical Example:**\nSuppose we have a list of integers that need to be packed and chunked:\n- **Integers**: [10, 20, 30, 40] (Suppose each integer occupies 8 bytes).\n- **Serialized Data**: A continuous byte array created from these integers.\n- **Padding**: If the total serialized length is not a multiple of 32, padding bytes are added.\n- **Chunks**: The data is divided into 32-byte chunks.\n- **Zero Padding for Tree**: If the number of chunks is not a power of two, additional zero-filled chunks are appended.\n- **Merkleization**: The chunks are then used as leaves in a Merkle tree to compute the root.\n\n### Mixing in the Length\n\nMixing in the length is a crucial step in the Merkleization process, particularly when handling lists and vectors. This step ensures that the final hash tree root accurately reflects both the content and the structure of the data, including its length. Let's break down how this concept is applied and why it's important.\n\n**Purpose of Mixing in the Length**\n\nMixing in the length is used to ensure that two different lists or vectors with similar contents but different lengths generate different hash tree roots. This is critical because without incorporating the length into the hash, two lists—one longer than the other but otherwise identical up to the length of the shorter list—would have the same hash tree root if only the content is hashed. This could lead to potential security vulnerabilities and inconsistencies within the data validation process.\n\n**An example of Mixing in the Length**\n\nThe example below illustrates that without including the length of the list, the Merkle root hashes for `a_root_hash` and `b_root_hash` remain the same despite representing two lists of different lengths. However, when the length is incorporated, the Merkle root hash `a_mix_len_root_hash` differs from both `a_root_hash` and `b_root_hash`. This distinction is crucial when dealing with lists or vectors of varying lengths in the merkleization.\n\n\n```python\n>>> from eth2spec.utils.ssz.ssz_typing import uint256, List\n>>> from eth2spec.utils.merkle_minimal import merkleize_chunks\n>>> a = List[uint256, 4](33652, 59750, 92360)\n>>> a_len = a.length()\n>>> a = List[uint256, 4](33652, 59750, 92360).encode_bytes()\n>>> b = List[uint256, 4](33652, 59750, 92360, 0).encode_bytes()\n>>> a_root_hash = merkleize_chunks([a[0:32], a[32:64], a[64:96]])\n>>> b_root_hash = merkleize_chunks([b[0:32], b[32:64], b[64:96], b[96:128]])\n>>> a_mix_len_root_hash = merkleize_chunks([merkleize_chunks([a[0:32], a[32:64], a[64:96]]), a_len.to_bytes(32, 'little')])\n>>> print('a_root_hash = ', a_root_hash)\na_root_hash = 0x3effe553b6091b1982a6850fd2a788943363e6f879ff796057503b76802edd9d\n>>> print('b_root_hash = ', b_root_hash)\nb_root_hash = 0x3effe553b6091b1982a6850fd2a788943363e6f879ff796057503b76802edd9d\n>>> print('a_mix_len_root_hash = ', a_mix_len_root_hash)\na_mix_len_root_hash = 0xeca15347139a6ad6e7eabfbcfd3eb3bf463af2a8194c94aef742eadfcc3f1912\n>>> \n```\n\n## Summaries and Expansions in SSZ Merkleization\n\nIn Ethereum PoS, the concepts of summaries and expansions are integral to managing state data efficiently. Summaries provide a compact representation of data structures, encapsulating essential verification information without the full details. Expansions, on the other hand, deliver the complete data set for thorough processing or when detailed information is required. Here are their benefits:\n\n- **Efficiency and Speed**: By employing summaries, validators can quickly verify state changes or validate transactions without processing entire data sets. This method significantly speeds up validations and reduces computational overhead. \n- **Reduced Data Load**: Summaries minimize the amount of data stored and transmitted, conserving bandwidth and storage resources. This is particularly beneficial for nodes with limited capacity, such as light clients, which rely on summaries for operational efficiency.\n- **Security Enhancements**: The cryptographic hashes included in summaries ensure the integrity of the data, enabling secure and reliable verification processes without accessing the full dataset.\n- **An Example**:\n - **BeaconBlock and BeaconBlockHeader**: The `BeaconBlockHeader` container acts as a summary, allowing nodes to quickly verify the integrity of a block without needing the complete block data from `BeaconBlock` container. `BeaconBlock` is the expansion.\n - **Proposer Slashing**: Validators use block summaries to efficiently identify and process conflicting block proposals, facilitating swift and accurate slashing decisions.\n\n## Merkleization for Basic Types\n\nLet's understand the Merkleization of basic types using an example. Below is a simple Merkle tree and we will follow the process of merkleization to get the merkle root hash.\n\n```mermaid\ngraph TD;\n A[\"A\"] --> HAB[\"H(A + B)\"]\n B[\"B\"] --> HAB\n C[\"C\"] --> HCD[\"H(C + D)\"]\n D[\"D\"] --> HCD\n HAB --> HROOT[\"Root: H(H(A+B) + H(C+D))\"]\n HCD --> HROOT\n```\n\n_Figure: Sample Merkle Tree._\n\nIn the above Merkle tree, the leaves of the tree are the four blobs of data, A, B, C, and D.\n\n- **Define the Data:**\n - In this example, we're dealing with four basic data items: A, B, C, and D. These are conceptualized as numbers (`10`, `20`, `30`, and `40` respectively) and will be represented in the Merkle tree as 32-byte chunks.\n- **Convert Data to 32-byte Chunks:**\n - Each data item is serialized into a 32-byte format using the `uint256` type from the SSZ typing system. Serialization involves converting the data into a format that is consistent and padded to ensure that each item is 32 bytes long.\n- **Pair and Hash the Leaves:**\n - Next, pairs of these serialized data chunks are concatenated and hashed.\n- **Hash the Results to Form the Root:**\n - Finally, the hashes from the previous step (`ab` and `cd`) are concatenated and hashed to form the Merkle root.\n- **Output the Merkle Root:**\n - The Merkle root is then converted to a hexadecimal string to make it readable.\n\nThis final Merkle root is a unique representation of the data `A`, `B`, `C`, and `D`. Any change in the input data would result in a different Merkle root, illustrating the sensitivity of the hash function to the input data. This characteristic is essential for ensuring data integrity in Ethereum.\n\n\n```python\n>>> from eth2spec.utils.ssz.ssz_typing import uint256\n>>> from eth2spec.utils.hash_function import hash\n>>> a = uint256(10).to_bytes(length = 32, byteorder='little')\n>>> b = uint256(20).to_bytes(length = 32, byteorder='little')\n>>> c = uint256(30).to_bytes(length = 32, byteorder='little')\n>>> d = uint256(40).to_bytes(length = 32, byteorder='little')\n>>> ab = hash(a + b)\n>>> cd = hash(c + d)\n>>> abcd = hash(ab + cd)\n>>> abcd.hex()\n'1e3bd033dcaa8b7e8fa116cdd0469615b29b09642ed1cb5b4a8ea949fc7eee03'\n```\n\n## Merkleization for Composite Types\n\nIn this section we learn how the `IndexedAttestation` composite type is Merkleized, using a detailed example to illustrate the process. This example provides clear instances of the Merkleization process applied to composite, list, and vector types. It also showcases how summaries and expansions are effectively demonstrated through this process.\n\n**Definition and Structure**\n\nThe `IndexedAttestation` is a composite type defined as follows:\n\n```python\nclass IndexedAttestation(Container):\n attesting_indices: List[ValidatorIndex, MAX_VALIDATORS_PER_COMMITTEE]\n data: AttestationData\n signature: BLSSignature\n```\n\n`IndexedAttestation` is composed of three primary components:\n\n - **attesting_indices:** A list of `ValidatorIndex`, representing the validators who are attesting.\n - **data:** An `AttestationData` container, holding various pieces of data pertinent to the attestation.\n - **signature:** A `BLSSignature`, which is a signature over the attestation.\n\n**Merkleization Process**\n\nThe Merkleization of `IndexedAttestation` involves computing the hash tree root of each component and combining these roots to form the overall hash tree root of the container. \n\n**Merkleizing `attesting_indices`:**\n\n- **Serialization and Padding:** First, the list of indices is serialized. Given the potential length of this list (up to the `MAX_VALIDATORS_PER_COMMITTEE`), it often requires padding to align with the 32-byte chunks required for hashing.\n- **Hashing:** The serialized data is hashed using the `merkleize_chunks` function, which handles the padding and constructs a multi-layer Merkle tree.\n- **Mixing in Length:** Since lists in SSZ can vary in length but have the same type structure, the length of the list is also hashed (mixed in) to ensure unique hash representations for different-sized lists.\n\n```python\nattesting_indices_root = merkleize_chunks(\n [\n merkleize_chunks([a.attesting_indices.encode_bytes() + bytearray(8)], 512),\n a.attesting_indices.length().to_bytes(32, 'little')\n ])\n```\n\n**Merkleizing data (`AttestationData`):**\n- **Handling Nested Structures:** `AttestationData` itself contains multiple fields (like `slot`, `index`, `beacon_block_root`, `source`, and `target`), each of which is individually serialized and Merkleized.\n- **Combining Hashes:** The hashes of these fields are then combined to produce the root hash of the `AttestationData`.\n\n```python\ndata_root = merkleize_chunks(\n [\n a.data.slot.to_bytes(32, 'little'),\n a.data.index.to_bytes(32, 'little'),\n a.data.beacon_block_root,\n merkleize_chunks([a.data.source.epoch.to_bytes(32, 'little'), a.data.source.root]),\n merkleize_chunks([a.data.target.epoch.to_bytes(32, 'little'), a.data.target.root]),\n ])\n```\n\n**Merkleizing signature:**\n\n- **Simple Hashing:** The `BLSSignature` is a fixed-length field and is directly hashed into three 32-byte chunks, which are then Merkleized to get the signature's root.\n\n```python\nsignature_root = merkleize_chunks([a.signature[0:32], a.signature[32:64], a.signature[64:96]])\n```\n\n**Combining Component Roots:**\n\n- The roots calculated from each component are then combined to compute the hash tree root of the entire `IndexedAttestation` container.\n```python\nindexed_attestation_root = merkleize_chunks([attesting_indices_root, data_root, signature_root])\n```\n\n**Verification of Final Root:**\n\n- The correct implementation of Merkleization of `IndexedAttestation` ensures that changes in any part of the data structure are reflected in the final root hash, providing a robust mechanism for detecting discrepancies and ensuring data consistency across all nodes in the network.\n\n```python\nassert a.hash_tree_root() == indexed_attestation_root\n```\n\nNow, you can visualize the full picture of the merkleization of `IndexedAttestation`:\n\n![merkleization of IndexedAttestation](../../images/merkelization-IndexedAttestation.png)\n**Merkleization of IndexedAttestation**\n\nHere is the full working code:\n\n```python\nfrom eth2spec.capella import mainnet\nfrom eth2spec.capella.mainnet import *\nfrom eth2spec.utils.ssz.ssz_typing import *\nfrom eth2spec.utils.merkle_minimal import merkleize_chunks\n\n# Initialise an IndexedAttestation type\na = IndexedAttestation(\n attesting_indices = [33652, 59750, 92360],\n data = AttestationData(\n slot = 3080829,\n index = 9,\n beacon_block_root = '0x4f4250c05956f5c2b87129cf7372f14dd576fc152543bf7042e963196b843fe6',\n source = Checkpoint (\n epoch = 96274,\n root = '0xd24639f2e661bc1adcbe7157280776cf76670fff0fee0691f146ab827f4f1ade'\n ),\n target = Checkpoint(\n epoch = 96275,\n root = '0x9bcd31881817ddeab686f878c8619d664e8bfa4f8948707cba5bc25c8d74915d'\n )\n ),\n signature = '0xaaf504503ff15ae86723c906b4b6bac91ad728e4431aea3be2e8e3acc888d8af'\n + '5dffbbcf53b234ea8e3fde67fbb09120027335ec63cf23f0213cc439e8d1b856'\n + 'c2ddfc1a78ed3326fb9b4fe333af4ad3702159dbf9caeb1a4633b752991ac437'\n)\n\n# A container's root is the merkleization of the roots of its fields.\n# This is IndexedAttestation.\nassert(a.hash_tree_root() == merkleize_chunks(\n [\n a.attesting_indices.hash_tree_root(),\n a.data.hash_tree_root(),\n a.signature.hash_tree_root()\n ]))\n\n# A list is serialised then (virtually) padded to its full number of chunks before Merkleization.\n# Finally its actual length is mixed in via a further hash/merkleization.\nassert(a.attesting_indices.hash_tree_root() ==\n merkleize_chunks(\n [\n merkleize_chunks([a.attesting_indices.encode_bytes() + bytearray(8)], 512),\n a.attesting_indices.length().to_bytes(32, 'little')\n ]))\n\n# A container's root is the merkleization of the roots of its fields.\n# This is AttestationData.\nassert(a.data.hash_tree_root() == merkleize_chunks(\n [\n a.data.slot.hash_tree_root(),\n a.data.index.hash_tree_root(),\n a.data.beacon_block_root.hash_tree_root(),\n a.data.source.hash_tree_root(),\n a.data.target.hash_tree_root()\n ]))\n\n# Expanding the above AttestationData roots by \"manually\" calculating the roots of its fields.\nassert(a.data.hash_tree_root() == merkleize_chunks(\n [\n a.data.slot.to_bytes(32, 'little'),\n a.data.index.to_bytes(32, 'little'),\n a.data.beacon_block_root,\n merkleize_chunks([a.data.source.epoch.to_bytes(32, 'little'), a.data.source.root]),\n merkleize_chunks([a.data.target.epoch.to_bytes(32, 'little'), a.data.target.root]),\n ]))\n\n# The Signature type has a simple Merkleization.\nassert(a.signature.hash_tree_root() ==\n merkleize_chunks([a.signature[0:32], a.signature[32:64], a.signature[64:96]]))\n\n# Putting everything together, we have a \"by-hand\" Merkleization of the IndexedAttestation.\nassert(a.hash_tree_root() == merkleize_chunks(\n [\n # a.attesting_indices.hash_tree_root()\n merkleize_chunks(\n [\n merkleize_chunks([a.attesting_indices.encode_bytes() + bytearray(8)], 512),\n a.attesting_indices.length().to_bytes(32, 'little')\n ]),\n # a.data.hash_tree_root()\n merkleize_chunks(\n [\n a.data.slot.to_bytes(32, 'little'),\n a.data.index.to_bytes(32, 'little'),\n a.data.beacon_block_root,\n merkleize_chunks([a.data.source.epoch.to_bytes(32, 'little'), a.data.source.root]),\n merkleize_chunks([a.data.target.epoch.to_bytes(32, 'little'), a.data.target.root]),\n ]),\n # a.signature.hash_tree_root()\n merkleize_chunks([a.signature[0:32], a.signature[32:64], a.signature[64:96]])\n ]))\n\nprint(\"Success!\")\n```\n\nYou can follow the instructions at [running the specs](https://eth2book.info/capella/appendices/running/) to execute the above code.\n\n## Resources\n\n- [Hash Tree Roots and Merkleization](https://eth2book.info/capella/part2/building_blocks/merkleization/)\n- [SSZ](https://ethereum.org/en/developers/docs/data-structures-and-encoding/ssz/)\n- [Protolambda on Merkleization](https://github.com/protolambda/eth2-docs?tab=readme-ov-file#ssz-hash-tree-root-and-merkleization)\n- [Running the specs](https://eth2book.info/capella/appendices/running/)" }, { "path": "docs/wiki/CL/overview.md", "content": "# Consensus Layer Overview\n\nThe main challenge a consensus protocol aims to solve is building a reliable distributed system on top of unreliable infrastructure. Research on consensus protocols dates back to the 1970s, but the scale of what Ethereum is trying to achieve is far more ambitious.\n\nIn Ethereum's consensus layer, the goal is to ensure that tens of thousands of independent nodes around the world stay reasonably synchronized. Each node keeps a ledger with the state of every account, and all these ledgers must match exactly. There can be no differences; the nodes must agree and do so quickly. This is what we mean by \"a reliable distributed system.\"\n\nThese nodes often use [consumer grade hardware](https://stakefromhome.com/) and communicate over internet connections that may be slow, lose data, or disconnect unexpectedly. Node operators might misconfigure their software or fail to update it. Additionally, there could be many bad actors running rogue nodes or tampering with communications for personal gain. This is what we mean by \"unreliable infrastructure.\"\n\n### Byzantine Fault Tolerance (BFT) and Byzantine Generals' Problem\n\nByzantine Fault Tolerance (BFT) is a property of distributed systems that allows them to function correctly even when some components fail or act maliciously. BFT is crucial in decentralized networks, where trust among nodes cannot be assumed. In other words, a system exhibiting BFT can tolerate Byzantine faults, which are arbitrary failures that include malicious behavior. For a system to be Byzantine fault-tolerant, it must reach consensus despite these faults. For more on the problem and practical solutions read [this](https://hackmd.io/@kira50/SknuPZMIC).\n\n## Introduction to Consensus Layer (CL)\n\n> Consensus is a way to build reliable distributed systems with unreliable components. Blockchain-based distributed systems aim to agree on a single history of transactions.\n>\n> Proof-of-work and Proof-of-stake are not consensus protocols, but enable consensus protocols. In Ethereum, Nodes and validators are the actors of the consensus system. Slots and epochs regulate consensus time. Blocks and attestations are the currency of consensus.\n\nThe Consensus Layer (CL) is a fundamental component that ensures the network's security, reliability, and efficiency. Originally, Ethereum utilized Proof-of-work (PoW) as its consensus mechanism, similar to Bitcoin. PoW, while effective in maintaining decentralization and security, has significant drawbacks, including high energy consumption and limited scalability. To address these issues, Ethereum has transitioned to Proof-of-Stake (PoS), a more sustainable and scalable consensus mechanism.\n\nThe Ethereum network consists of many individual nodes. Each node operates independently and communicates over the Internet, which is often unreliable and asynchronous.\n\nUsers send transactions to this network of nodes, and the consensus protocol ensures that all honest nodes eventually agree on a single, consistent transaction history. This means they agree on the order of transactions and their outcomes. For example, if I have 1 ETH and tell the network to send it to both Alice and Bob at the same time, the network must eventually agree on whether I sent it to Alice or Bob. It would be a failure if both Alice and Bob received the Ether, or if neither did. A consensus protocol is the process that enables this agreement on transaction order.\n\nEthereum's consensus protocol actually _bolts together_ two different consensus protocols. One is called [LMD GHOST](/wiki/CL/gasper.md?lmd-ghost), the other [Casper FFG](/wiki/CL/gasper.md?casper-ffg). The combination has become known as [Gasper](/wiki/CL/gasper.md). In subsequent sections we will be looking at these both separately and in combination.\n\n## Proof-of-work and Proof-of-stake\n\nThis is a good point to clarify that neither Proof-of-work (PoW) nor Proof-of-Stake (PoS) are consensus protocols by themselves. They are often incorrectly referred to as such, but they are actually mechanisms that enable consensus protocols. Both PoW and PoS primarily serve as Sybil resistance mechanisms, placing a cost on participating in the protocol. This prevents attackers from overwhelming the system cheaply.\n\nHowever, both PoW and PoS are closely linked to the consensus mechanisms they support through [fork choice](/wiki/CL/cl-architecture.md?id=fork-choice-rules) rules. They help assign a weight or score to a chain of blocks: in PoW, it's the total computational work done; in PoS, it's the total value staked that supports a particular chain. Beyond these basics, PoW and PoS can support various consensus protocols, each with its own dynamics and trade-offs.\n\n### Blockchains\n\nThe basic element of a blockchain is the block. A block contains a set of transactions assembled by a leader (block proposer). The contents of a block can vary based on the protocol.\n\n- The payload of a block on Ethereum's execution chain is a list of user transactions.\n- In the pre-Merge PoS Beacon Chain, a block's payload was mostly a set of attestations by validators.\n- Post-Merge Beacon Chain blocks also include the execution payload (user transactions).\n- After [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844)(Deneb upgrade), blocks now also contain commitments to opaque data blobs alongside user transactions.\n\nExcept for the Genesis block, each block builds on and points to a parent block, forming a chain of blocks: a blockchain. The goal is for all nodes on the network to agree on the same canonical blockchain history.\n\n\n\n
\n\n![Blockchain](../../images/cl/blockchain.svg)\n\n
\n\n_Time moves from left to right and, except for the Genesis block, each block points to the parent block it builds on._\n\n
\n
\n\nThe chain grows as nodes add new blocks to its tip. This is done by temporarily selecting a \"leader\", the node that extends the chain. In PoW, the leader is the miner who first solves the PoW puzzle for its block. In Ethereum's PoS, the proposer(leader) is pseudo-randomly selected from active validator set.\n\nThe leader (block proposer) adds a block to the chain, choosing and ordering its contents. The block must be valid according to protocol rules, or the network will ignore it. Using blocks is an optimization. Adding individual transactions one by one would create a huge consensus overhead. So blocks are batches of transactions, In Ethereum's execution chain, block size is limited by the block gas limit (the amount of work needed to process the transactions). [Beacon block](/wiki/CL/beacon-api.md?id=beaconblockbody) sizes are limited by hard-coded constants.\n\n## Transition to Proof-of-Stake\n\n> The engine was changed mid-flight! September 15, 2022 — the day Ethereum switched to Proof-of-Stake. That new engine is the Consensus Layer, formerly known as Ethereum 2.0’s Beacon Chain.\n\nThe Paris hard fork (The merge) in Ethereum was activated based on \"terminal total difficulty\" (TTD) instead of block height to avoid risks like malicious forks. This ensures the transition to Proof-of-Stake (PoS) occurs only when the cumulative difficulty reaches a critical threshold. The terminal block is the last Proof-of-work (PoW) block where its total difficulty surpasses a predefined threshold, ensuring security. The total difficulty is calculated recursively, reflecting the computational effort in the blockchain. \n\nThis is relevant because testnets, devnets and any Ethereum network running the latest software needs to activate the Merge - not by block height but by Total Terminal Difficulty (TTD). More details on the [transition criteria](https://hackmd.io/@kira50/rJ2y7jImR) and [Total Terminal Difficulty](https://bordel.wtf).\n\nThe merge introduces the following:\n\n- **Beacon Chain Takes Over**: The Beacon Chain, already running in parallel with the Ethereum mainnet, assumes the responsibility for processing new blocks. Under PoS, blocks are validated by validators who stake their ETH to participate in the consensus mechanism, rather than by miners solving cryptographic puzzles.\n\n- **Security and Efficiency**: This transition not only aims to enhance the security of the Ethereum network by making it more decentralized but also significantly reduces its energy consumption, addressing one of the major criticisms of traditional PoW systems.\n\n- **New Consensus Mechanism**: The consensus under PoS is achieved through a combination of staking, attestation by validators, and algorithms that randomly select block proposers and committees to ensure the network remains secure and transactions are processed efficiently.\n\n### Beacon Chain Introduction\nThe Beacon Chain plays a crucial role in managing the PoS consensus. It oversees validators who propose and attest to new blocks, ensuring the network’s integrity and security. Validators are selected based on a number of criteria, one of them being the amount of ETH they stake, which also acts as collateral against dishonest behavior. Some high level responsibilities of validators are:\n\n- **Staking ETH**: Validators must stake a minimum of 32 ETH to participate.\n- **Proposing Blocks**: A Validator is randomly selected to propose a new block. They must construct valid blocks and broadcast them to the network\n- **Attesting Blocks**: Validators attest to the validity of blocks proposed by others. Attestations are essentially votes on the validity of the blocks, ensuring consensus.\n- **Participating in Consensus**: Validators participate in consensus by voting on the state of the blockchain at regular intervals, helping to finalize the blockchain's state.\n\nThe Paris hard fork was a pivotal event in Ethereum's history, setting the stage for more scalable, sustainable, and secure operations. It represents Ethereum's commitment to innovation and its responsiveness to the broader societal concerns about the environmental impact of cryptocurrency mining.\n\n## Beacon Chain and its Preliminaries\n\nThe Beacon Chain is the backbone of Ethereum’s consensus. It coordinates validators, manages the PoS protocol, and ensures consensus across the network. This section will cover the anatomy of Beacon chain.\n\n### Validators\n\nValidators are essentially the participants in the PoS Protocol. They propose and validate new blocks, ensuring the integrity and security of the blockchain. Validators must stake ETH as collateral, aligning their interests with the network’s health. Validators are chosen to propose blocks based on several factors:\n\n- **Staked Ether**: To become a validator, an individual must deposit a minimum of 32 ETH into the official deposit contract. Each validator can stake a maximum of 2048 ETH. This ETH acts as collateral to incentivize honest behavior. The validator's ETH is at risk if they fail to perform their duties or engage in malicious activities.\n- **Randomness**: The selection process incorporates cryptographic randomness to prevent predictability and manipulation. This is achieved through the [RANDAO](https://inevitableeth.com/ethereum/randao) and [VDF (Verifiable Delay Function)](https://inevitableeth.com/ethereum/vdf) mechanisms.\n- **Committees**: Validators are grouped into committees for block proposal and attestation. Each committee is responsible for validating and attesting to blocks, ensuring a decentralized and secure validation process.\n\n### Slots and Epochs\n\nEach slot is 12 seconds and an epoch is 32 slots: 384 seconds or 6.4 minutes. Each slot has a validator assigned to propose a block, while committees of validators attest to the block’s validity.\n\nA slot is a chance for a block to be added to the Beacon Chain. Every 12 seconds, one block is added. Validators need to be roughly [synchronized with time](https://ethresear.ch/t/network-adjusted-timestamps/4187). A slot is like the block time, but slots can be empty. The Beacon Chain genesis block is at Slot 0.\n\n\n\n\n
\n\n![Diagram for slots and epoch](../../images/cl/slots-and-epochs.png)\n\n
\n\n_The first 32 slots are in Epoch 0. Genesis block is at Slot 0._\n\n
\n
\n\n\n### Validators and Attestations\n\nA block proposer is a validator that has been pseudo-randomly selected to build a block. Validators propose blocks and attest to the blocks proposed by others. Most of the time, validators are attesters that vote on blocks. These votes are recorded in the Beacon Chain and determine the head of the Beacon Chain.\n\nAttestations are votes on the validity of the blocks, which are aggregated into the Beacon Chain to ensure consensus. \n\n\n\n
\n\n![Diagram for Validator selection](../../images/cl/validators.png)\n\n
\n\n_A slot can be missed as you can see in this diagram on 28th slot_\n\n
\n
\n\nAn **attestation** is a validator’s vote, weighted by the validator’s stake. Attestations are broadcasted by validators in addition to blocks. Validators also police each other and are rewarded for reporting other validators that make conflicting votes, or propose multiple blocks.\n\nThe contents of the Beacon Chain is primarily a registry of validator addresses, the state of each validator, and attestations. Validators are activated by the Beacon Chain and can transition to states\n\n**IMPORTANT NOTE on Staking Validators Semantics:** *In Ethereum's PoS, users activate validators by staking ETH, similar to buying hardware in PoW. Stakers are associated with the amount staked, while validators have a minimum activation balance of 32 ETH and a maximum effective balance of 2048 ETH each. Validators are run by validator clients, which use a beacon node to follow and read the Beacon Chain. A single validator client can manage multiple validators.*\n\n### Committees\n\nCommittees are groups of at least 128 validators assigned to each slot for added security. An attacker has less than a 1 in a trillion chance of controlling ⅔ of a committee.\n\nThe concept of a randomness beacon that emits random numbers for the public, is how Beacon Chain got it's name. The Beacon Chain enforces consensus on a pseudorandom process called RANDAO.\n\n\n
\n\n![Diagram for Validator selection](../../images/cl/RANDAO.png)\n\n
\n\n_At every epoch, a pseudorandom process RANDAO selects proposers for each slot, and shuffles validators to committees._\n\n
\n
\n\n**Validator Selection:**\n- As mentioned earlier, Proposers are chosen by RANDAO, weighted by validator balance.\n- A validator can be both a proposer and a committee member for the same slot, but this is rare (1/32 probability).\n\nThe sketch depicts a scenario with less than 8,192 validators, otherwise there would be at least two committees per slot.\n\n\n\n
\n\n![Diagram for Committees](../../images/cl/committees.png)\n\n
\n\nThe diagram is a combined depiction of what happened in 3 slots:\n- Slot 1: A block is proposed and attested by two validators; one validator is offline.\n- Slot 2: A block is proposed, but one validator misses it and attests to the previous block.\n- Slot 3: All validators in Committee C attest to the same head, following the LMD GHOST rule.\n\nValidators attest to their view of the Beacon Chain head using the LMD GHOST rule.\nAttestations help finalize blocks by reaching consensus on the blockchain’s state.\n\n**Committee Size and Security:**\n- With more than 8,192 validators, multiple committees per slot are formed.\n- Committees must be at least 128 validators for optimal security.\n- Security decreases with fewer than 4,096 validators, as committee sizes drop below 128.\n\n> At every epoch, validators are evenly divided across slots and then subdivided into committees of appropriate size. All of the validators from that slot attest to the Beacon Chain head. A shuffling algorithm scales up or down the number of committees per slot to get at least 128 validators per committee. More details on shuffling can be found in [proto's repo.](https://github.com/protolambda/eth2-docs#shuffling)\n\n### Blobs\n\n[EIP-4844](https://eips.ethereum.org/EIPS/eip-4844), also known as proto-danksharding, is part of the Deneb/Cancun hardfork. It introduces a data availability layer to Ethereum, allowing for the temporary storage of arbitrary data on the blockchain. This arbitrary data stored this way are called `blobs`, and each block can have 3 ~ 6 blob sidecars (wrappers for blobs). EIP-4844 marks Ethereum's first step towards sharding and scalability, enabling Layer 2 solutions (L2s) to use this data availability layer to lower gas fees and process more transactions.\n\n### Design and Implementation\n\nA key design decision in EIP-4844 is the use of [KZG commitments](/wiki/Cryptography/KZG.md) to verify blobs and support future proposer-builder separation. To use KZG commitments, a Trusted Setup is needed. For the Deneb hardfork, a [KZG Ceremony](https://github.com/ethereum/kzg-ceremony) was conducted to create this Trusted Setup.\n\n\n\n
\n\n![Diagram for Blobs](../../images/cl/blobs.png)\n\n
\n\n### Storage Requirements\n\nThe most significant impact on node operators is the increased storage requirement. Node runners will need more storage:\n\n```\n131,928 ssz bytes per blob * 4096 blobs retention period * \n32 potential blocks per epoch * 3~6 blob sidecars per block\n\n= 52~104GB\n```\n\nBy default, these blobs will be retained for 4096 epochs, and clients would prune the oldest blobs once the retention period is reached.\n\n### Checkpoints and Finality\n\nAt the end of each epoch, checkpoints are created. A checkpoint is a block in the first slot of an epoch. If there is no such block, then the checkpoint is the preceding most recent block. There is always one checkpoint block per epoch. A block can be the checkpoint for multiple epochs.\n\nA block becomes a checkpoint if it receives attestations from a majority of validators. Checkpoints are used to finalize the blockchain's state. A block is considered final when it is included in two-thirds of the most recent checkpoint attestations, ensuring it cannot be reverted.\n\n\n
\n\n![Diagram for checkpoints](../../images/cl/checkpoints.jpg)\n\n
\n\n_Checkpoints for a scenario where an epoch contain 64 slots_\n\n
\n
\n\nFor example, if Slots 65 to 128 are empty, the Epoch 2 checkpoint defaults to the block at Slot 64. Similarly, if Slot 192 is empty, the Epoch 3 checkpoint is the block at Slot 180. **Epoch boundary blocks (EBB)** is a term in some literature (such as the [Gasper](https://arxiv.org/abs/2003.03052) paper, the source of the diagram above and a later one), and they can be considered synonymous with checkpoints.\n\nValidators cast two types of votes: **LMD GHOST** votes for blocks and **Casper FFG** votes for checkpoints. An **FFG** vote includes a source checkpoint from a previous epoch and a target checkpoint from the current epoch. For example, a validator in Epoch 1 might vote for a source checkpoint at the genesis block and a target checkpoint at Slot 64, repeating the same vote in Epoch 2. Only Validators assigned to a slot cast LMD GHOST votes, while all validators cast FFG votes for epoch checkpoints.\n\n#### Supermajority and Finality\n\nA supermajority, defined as ⅔ of the total validator balance, is required for a checkpoint to be justified. For instance, if validators have balances of 8 ETH, 8 ETH, and 32 ETH, a supermajority needs the vote of the 32 ETH validator. Once a checkpoint receives a supermajority, it becomes justified. If the subsequent epoch's checkpoint also achieves justification, the previous checkpoint is finalized, securing all preceding blocks. Typically, this process spans two epochs (12.8 minutes).\n\nWhen a user transaction is included in a block, on average it would be somewhere in the middle of an epoch. It takes half an epoch (about 3.2 minutes) to reach the next checkpoint, suggesting transaction finality of 2.5 epochs: 16 minutes. Optimally, more than ⅔ of attestations will have been included by the 22nd (2/3rd of 32) slot of an epoch. Thus, transaction finality is an average of 14 minutes (16+32+22 slots). Block confirmations emerge from a block’s attestations, then move to its justification, to its finality. Use cases can decide whether they need finality or an earlier safety threshold is sufficient.\n\n\n
\n\n![Diagram for Finality](../../images/cl/finalization.png)\n\n
\n\n_Example of one checkpoint getting justified (Slot 64) and finalizing a prior checkpoint (Slot 32)._\n\n
\n
\n\n**What happened at the Beacon Chain head:**\nAt Slot 96, a block is proposed that includes attestations (votes) for the Epoch 2 checkpoint. These attestations reach the required two-thirds supermajority, justifying the Epoch 2 checkpoint. This action finalizes the previously justified Epoch 1 checkpoint. When the Epoch 1 checkpoint is finalized, all preceding blocks (up to Slot 32) also become final. Finality calculations happen at epoch boundaries, but attestations accumulate with each block.\n\n**What could have happened from genesis to the head:**\n- **Scenario 1:**\n - Proposers from Slot 1 to Slot 63 propose blocks.\n - Each block in Epoch 1 contributes attestations for the checkpoint at Slot 32, eventually reaching 55%.\n - The block at Slot 64 includes additional attestations, bringing support for the Slot 32 checkpoint to 70%, causing its justification.\n - Throughout Epoch 2, the Slot 64 checkpoint gathers attestations but doesn't reach the two-thirds threshold until Slot 96, where it is justified.\n - Justifying the Epoch 2 checkpoint finalizes the Epoch 1 checkpoint and all preceding blocks.\n\n- **Scenario 2:**\n - The checkpoint at Epoch 1 could reach the two-thirds supermajority before the next epoch.\n - For example, blocks from Slot 32 to Slot 54 could provide enough attestations to justify the checkpoint at Slot 32.\n - In this case, the Slot 32 checkpoint would be justified within its current epoch but would need the next epoch to finalize.\n\n**Special Cases:**\nThe justification of a checkpoint can sometimes finalize blocks from two or more epochs ago, especially during periods of high latency, network partitions, or attacks, You can find more such cases, discussed in the Gasper paper. These scenarios are exceptional and not the norm.\n\n\n#### Closer Look on Attestations\n\nValidators submit one attestation per epoch, containing both an LMD GHOST and an FFG vote. These attestations have 32 chances per epoch for inclusion on-chain, with earlier inclusions receiving higher rewards. This means a validator may have two attestations included on-chain in a single epoch. Validators are rewarded the most when their attestation is included on-chain at their assigned slot; later inclusion has a decayed reward. To give validators time to prepare, they are assigned to committees one epoch in advance. Proposers are only assigned to slots once the epoch starts. Nonetheless, [secret leader election](https://ethresear.ch/t/low-overhead-secret-single-leader-election/5994) research aims to mitigate attacks or bribing of proposers.\n\nConsider a block proposed at Slot 64 containing attestations for the Epoch 2 checkpoint. This scenario can finalize the checkpoint at Slot 32. The finality of the Slot 32 checkpoint, once achieved, propagates backward, securing all preceding blocks.\n\nIn essence, Committees allow for the technical optimization of combining signatures from each attester into a single aggregate signature. When validators in the same committee make the same LMD GHOST and FFG votes, their signatures can be aggregated.\n\n### Staking Rewards and Penalties\n\nEthereum’s PoS system employs a comprehensive set of rewards and penalties to incentivize validator behavior and maintain network security. This section covers six key aspects of these incentives:\n\n**1. Attester Rewards:**\nValidators earn rewards for making attestations (LMD GHOST and FFG votes) that align with the majority of other validators. Attestations included in finalized blocks are more valuable.\n\n**2. Attester Penalties:**\nValidators are penalized for failing to attest or for attesting to blocks that do not get finalized. These penalties ensure validators remain active and aligned with the network’s consensus.\n\n**3. Typical Downside Risk for Stakers:**\nStakers can estimate their downside risk by comparing potential earnings and penalties. An honest validator earning 10% in a year could lose up to 7.5% for poor performance. Minor penalties apply for short-term inactivity, while prolonged offline periods incur larger penalties.\n\n**4. Slashings and Whistleblower Rewards:**\nSlashing penalizes validators for serious protocol violations. Penalties range from over 0.5 ETH up to the entire stake. For example, a validator committing a slashable offense loses at least 1/32 of their balance and is deactivated. Additional penalties are proportional to the number of validators slashed simultaneously. A whistleblower who reports a slashable offense receives a reward, which currently goes to the block proposer.\n\n**5. Proposer Rewards:**\nBlock proposers receive substantial rewards for proposing blocks that get finalized. Consistently performing validators gain approximately a 1/8 boost to their total rewards. Additionally, proposers receive small rewards for including slashing evidence in their blocks.\n\n**6. Inactivity Leak Penalty:**\nThe inactivity leak is a severe penalty designed to ensure the network’s finality. If finality is delayed for more than four epochs, validators suffer increasing penalties until a checkpoint is finalized. This mechanism drains the balances of inactive validators, leading to their forced exit, thus allowing active validators to form a ⅔ majority to resume finality. During an inactivity leak, only proposer and whistleblower rewards are earned, while attester rewards are zero.\n\n\n### **Slashable Offenses:**\nThere are four conditions under which a validator can be slashed:\n- **Double Proposal:** Proposing more than one block for their assigned slot.\n- **LMD GHOST Double Vote:** Attesting to different Beacon Chain heads for the same slot.\n- **FFG Surround Vote:** Casting an FFG vote that surrounds or is surrounded by a previous FFG vote by the same validator.\n- **FFG Double Vote:** Casting two FFG votes for different targets in the same epoch.\n\n## Beacon Chain Validator Activation and Lifecycle:\n\nA validator requires a minimum balance of 32 ETH to be activated. Validators are deactivated if their balance falls to 16 ETH, with any remaining balance withdrawable. Validators can also voluntarily exit after serving 2,048 epochs (approximately nine days). \n\nUpon exit, there is a delay of four epochs before withdrawal, during which validators can still be slashed. \n\nHonest validators can withdraw their balance in about 27 hours, whereas slashed validators face a delay of approximately 36 days (8,192 epochs).\n\n\n
\n\n![Diagram for Validator Lifecycle](../../images/cl/validator-lifecycle.png)\n\n
\n\nTo prevent rapid changes in the validator set, mechanisms limit how many validators can be activated or exited per epoch. The Beacon Chain also employs effective balances for technical optimization, which change less frequently than actual validator balances.\n\n#### Overall Effects\nAt every epoch, validators are evenly divided across slots and then subdivided into committees of appropriate size. Validators can only be in one slot, and in one committee. Collectively:\n\n- All validators in an epoch attempt to finalize the same checkpoint: FFG vote\n- All validators assigned to a slot attempt to vote on the same Beacon Chain head: LMD GHOST vote\nOptimal behavior rewards validators the most.\n\nThe Beacon Chain's introduction on December 1, 2020, began with 21,063 validators. The number of validators can decrease with slashings or voluntary exits, or more stakers can join and be activated. Fast forward to today(15th May, 2024) there are more than 1,000,000 validators that are active on Ethereum Network. The world has never seen a scalable platform for decentralized systems and applications like Ethereum.\n\n\n\n\n### References\n\n- [Beacon Chain Explainer from ethos.dev](https://ethos.dev/beacon-chain)\n- [Evolution of Ethereum Proof-of-Stake](https://github.com/ethereum/pos-evolution/blob/master/pos-evolution.md)\n- Alt Explainer, [Ethereum's Proof-of-Stake consensus explained](https://www.youtube.com/watch?v=5gfNUVmX3Es)\n- [Eth2 Handbook by Ben Edgington](https://eth2book.info/capella/part2/consensus/)\n- [MaxEB](https://eips.ethereum.org/EIPS/eip-7251)\n" }, { "path": "docs/wiki/CL/syncing.md", "content": "> [Subjective](https://dictionary.cambridge.org/dictionary/english/subjective): influenced by or based on personal beliefs or feelings, rather than based on facts \n> [Objective](https://dictionary.cambridge.org/dictionary/english/objective): based on real facts and not influenced by personal beliefs or feelings (scroll down on the link)\n\n## Background\n\nLet's make a distinction between \"objectivity\" and \"subjectivity\" in the context of information theory and blockchains. If a piece of information is *completely verifiable* for its *correctness* it is *objective*. If its correctness is not *fully verifiable* (some degree of belief goes into it) then it is \"subjective\". In reality, most pieces of information lie in the spectrum in between objectivity and subjectivity. \n\nFor example, prior to the merge, if a client started with a genesis block then it could *objectively* verify every block that came after it. To do this a client would ask for the latest \"final\"(will come to this later) head of the blockchain from its peers and then backtrack all the way to genesis by querying for parent blocks (a.k.a the history). Since the parent hash is encoded into a block it is easy to verify all the queried parent blocks. When the client reaches genesis it can deem the entire history as *correct* and itself as ***synced***. \n\n> different syncing mechanisms exist today. What is described above is the general overview of a \"full\" sync\n\nAltering the history of the chain required an ungodly amount of computational power(Proof-of-Work) making the verified history(pre-merge) *objective*. But there is still some amount of trust put into the genesis block being correct. But it can be argued that it is *weakly objective* rather than *subjective* because most clients come packaged with the genesis block and its checksum. \n\n> A \"final\" block was considered to be the 7th block from the current head of the blockchain, since reversing 6 blocks worth of PoW was considered difficult.\n\nWith the merge, Ethereum brought in membership(validators) and voting for its new consensus mechanism. Moreover, the consensus mechanism was logically isolated from the history and execution mechanism, referred to as the consensus layer(CL) and the execution layer(EL). While the history mechanism mostly remains the same, the latest final block required for syncing is obtained from the consensus layer. In return, the EL verifies the correctness of a block's execution (smart contracts etc.) for the CL to take a vote on the block and gather *consensus*. However, the change in the consensus mechanism made genesis syncing [\"unsafe\"](https://docs.teku.consensys.io/concepts/weak-subjectivity#sync-outside-the-weak-subjectivity-period). * *Enter weak-subjectivity* *\n\n> The new consensus mechanism also brought in several non-trivial nuances with it. Understanding these nuances is critical for understanding weak subjectivity(next section). This is a great starter: https://ethos.dev/beacon-chain\n\n## Syncing in Weak Subjectivity\n\nWhen a validator exits the chain, its right to participate in the consensus process is revoked. The validator can no longer vote/attest for any future blocks. However, *the validator can re-vote/re-attest for any of the **past** blocks*. If enough exited validators re-attest a past block (a past fork block), they create an alternate history of the chain. A sync-**ed** node that is at the canonical head wouldn't care about the equivocation (alternate history) since it has already processed the validator exit. However, a node that is sync-**ing** does not have any way of knowing the future state of the validator and might follow the wrong chain. To avoid this, the direction of syncing is reversed for the beacon chain. This is the first major difference between beacon block syncing and execution block syncing.\n\nThe second difference lies in the anchor of trust in information. Since the history of the chain can be changed under certain conditions the sync target cannot be objectively verified i.e. we can never concretely prove its existence in the canonical chain. Hence, there is a significant amount of trust placed in the sync target and it remains subjective. Because of the trust involved, sync targets (named weak subjectivity checkpoints) are shared out-of-band since random peer connections in the p2p layer of Ethereum cannot be trusted. It is important to note that, since the sync target is a \"finalized\" checkpoint it remains *weakly* subjective. In other words, its allows some degree of verification for its correctness (probably just not for its existence).\n\nThe third difference lies in the timing of the chain. A node that is out-of-sync for enough time can also be subject to the same attack. Theoretically, the amount of time should allow enough validators to exit and launch an attack. This time period is known as the ***weak subjectivity period***. This time period also applies to the sync target. If the backfilling process (beacon chain) or the execution layer takes too much time to sync, then the target becomes *stale*. Therefore, while the execution layer is syncing (backfilling is usually fast enough), new beacon blocks are continuously imported without checking their execution payload of the new heads. This is referred to as *optimistically* importing blocks.\n\nTherefore a weak subjectivity sync follows the steps defined below:\n1. *Obtain a weak subjectivity checkpoint out-of-band*\n2. *Backfill blocks all the way back to genesis from the weak subjectivity checkpoint*\n3. *Update the target header for the execution chain*\n4. *Optimistically follow the head of the chain and continuously update the target header for the execution chain*\n5. *Once the EL is synced, then mark the CL slots as verified post-verification. The node may now be considered fully synced*\n\n## Useful Links\n\n1. https://docs.prylabs.network/docs/how-prysm-works/optimistic-sync\n2. https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/weak-subjectivity/\n3. https://www.symphonious.net/2019/11/27/exploring-ethereum-2-weak-subjectivity-period/\n4. https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity\n5. https://notes.ethereum.org/@adiasg/weak-subjectvity-eth2\n6. https://blog.ethereum.org/2016/05/09/on-settlement-finality\n" }, { "path": "docs/wiki/Cryptography/KZG.md", "content": "# KZG Polynomial Commitment Scheme\n\n## [TLDR](#tldr)\nThe KZG (Kate, Zaverucha, and Goldwasser) commitment scheme is like a cryptographic vault for securely locking away polynomials (mathematical equations) so that you can later prove you have them without giving away their secrets. It's like making a sealed promise that you can validate without ever having to open it up and show the contents. Using advanced math based on elliptic curves, it enables efficient, verifiable commitments that are a key part of making blockchain transactions more private and scalable. This scheme is especially important for Ethereum's upgrades, where it helps to verify transactions quickly and securely without compromising on privacy.\n\nKZG is a powerful cryptographic tool that supports a wide range of applications within the Ethereum ecosystem and other cryptographic applications. Its distinctive features are leveraged in proving schemes to enhance scalability and privacy in various applications.\n\n\n## [Motivation](#motivation)\n\n### [ZKSNARKs](#zksnarks)\nLearning about Polynomial Commitment Schemes (PCS) is important because they play a key role in creating Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge (ZKSNARKs). ZKSNARKs are special cryptographic methods that allow someone (the prover) to show to someone else (the verifier) that they know a specific piece of information (like a number) without revealing that information. This is done by using PCS and Interactive Oracle Proofs (IOP) together.\n\n*Modern ZKSNARK = Functional Commitment Scheme + Compatible Interactive Oracle Proof (IOP)*\n\n\n### [Use cases in Ethereum Ecosystem](#use-cases-in-ethereum-ecosystem)\nKZG commitment scheme has emerged as a pivotal technology in the Ethereum ecosystem, particularly in the context of Proto-Danksharding and its anticipated evolution into Danksharding. This commitment scheme is a cornerstone of many Zero-Knowledge (ZK) related applications within Ethereum, enabling efficient and secure verification of data without revealing the underlying information.\n\nEthereum-based applications utilizing the KZG (Kate, Zaverucha, and Goldberg) scheme include:\n\n- **Proto-Danksharding (EIP-4844)**: This proposal aims to reduce the cost of posting data on Ethereum's Layer 1 for rollups by using KZG for its polynomial commitment scheme. It introduces a \"blob-carrying transaction\" type to accommodate substantial data blobs, with only a commitment to the data blob being accessible from the execution layer.\n\n- **Data Availability Sampling**: PCS enable a critical feature known as Data Availability Sampling (DAS) in Ethereum roadmap, which allows validators to confirm the correctness and availability of data blobs without downloading the entire data. This capability is facilitated by the unique properties of PCS, enabling efficient verification processes in blockchain applications like Ethereum's Danksharding.\n\n- **PSE's Summa, Proof of Solvency Protocol**: Ethereum Foundation's PSE group project, Summa, leverages KZG commitments in its Proof of Solvency protocol. This allows centralized exchanges and custodians to demonstrate that their total assets exceed their liabilities, all while keeping user balance information private.\n \n- **Scroll's zkRollups**: Scroll, a native zkEVM Layer 2 for Ethereum, uses KZG to generate commitments to a collection of polynomials that encapsulate computations. This allows verifiers to request evaluations at random points to validate the accuracy of the computation represented by the polynomials.\n\n- **Jellyfish**: Jellyfish employs the KZG commitment scheme to generate commitments to polynomials during the commitment phase. It leverages the homomorphic properties of KZG for efficient evaluation of the polynomial at any point without revealing its coefficients.\n\n- **Hyperplonk**: Hyperplonk utilizes the multi-linear KZG commitment, indicating its application in scenarios requiring multi-linear polynomial commitments.\n\n\n## [Goal](#goal)\nNow that we are motivated to learn PCS, let us get started with defining what is our goal i.e. what is the exact problem we want to solve with KZG scheme. \n\nSay we have a function or polynomial $f(x)$ defined as $f(x) = f_0 + f_1x + f_2x^2 + \\ldots + f_dx^t$. The degree of $f(x)$ is $t$.\n\nOur main goal with KZG scheme is that we want to prove to someone that we know this polynomial without revealing the polynomial, i.e. coefficients of the polynomial.\n\nIn practice what we exactly do is that we prove that we know a specific evaluation of this polynomial at a point $x=a$. \n\nWe write this, $f(a)$, for some $x=a$. \n\n## [Prerequisite Knowledge](#prerequisite-knowledge)\nThere are some important concepts we need to know before we can move further to understand KZG scheme. Fortunately, we can get an Engineering level understanding of the KZG scheme from just enough high school mathematics. We will try to gain some intuition on advanced concepts and their important properties without knowing them intimately. This can help us see the KZG protocol flow without bogged down by the advanced mathematics.\n\nWe need to know:\n\n### [Modular Arithmetic](#modular-arithmetic)\nAn analog clock illustrates modular arithmetic as hours cycle back after reaching their limit. For KZG, it's enough to know simple arithmetic—adding, subtracting, multiplying, and dividing—along with using the modulus operation, just like a clock resets after 12 or 24 hours.\n\n\n### [Finite Field of order prime p](#finite-field-of-order-prime)\nA finite field of order prime $p$, we denote it by $\\mathbb F_p$, is a special set of numbers, { $\\{1, 2, 3, \\ldots, p-1\\}$ }, where you can do all the usual math operations (addition, subtraction, multiplication, and division, except by zero) and still follow the rules of arithmetic. \n\nThe \"order\" of this set is the number of elements it contains, and for a finite field of order prime $p$, this number is a prime number. The most common way to create a $\\mathbb F_p$ is by taking the set of all integers greater than or equal to $0$ and dividing them by $p$, keeping only the remainders. This gives us a set of numbers from $0$ to $p-1$ that can be used for arithmetic operations. For example, if $p = 5$, the set would be {0, 1, 2, 3, 4}, and you can add, subtract, multiply, and divide these numbers in a way that follows the rules of arithmetic. This set is a finite field of order 5, we denote this by $\\mathbb F_5$, because it has exactly 5 elements, and it's a prime number.\n\nWhen we do modular arithmetic operations in the finite field $\\mathbb F_p$, we have a nice \"wrap around\" property i.e. the field behaves as if it \"wraps around\" after reaching $(p - 1)$. \n\nIn general, when we define a finite field, we define, the order $p$ of the field and an arithmetic operation like addition or multiplication. If it is addition, we denote the field by $(\\mathbb F_p, +)$. If it is multiplication, we denote it by $(\\mathbb F^*_p, +)$. The `*` is telling us to exclude the zero element from our field so that we can satisfy all the required properties of the finite field i.e. mainly we can divide the numbers and find inverse of all elements. If we include the zero element, we can't find the inverse of zero element.\n\nIn the next section, we will learn how generators of a Group enable the KZG commitment scheme to function as an efficient, secure, and verifiable method of committing to polynomials, making it a powerful tool for cryptographic protocols, particularly in blockchain technologies where these properties are very important.\n\n### [Group](#group)\nA Group is conceptually similar to a finite field, although with a few minor variations. An important difference is that in a group, we only have one arithmetic operation on the set, typically addition or multiplication as opposed to finite field with both addition and multiplication. Similarly to finite field, group elements must have an inverse and meet all its requirements, explained in the example below.\n\nThe notation is ($\\mathbb G, +)$ for a Group with addition as the group operation, ($\\mathbb G^*, .)$ for Group with multiplication operation; the `*` is telling to exclude zero element to avoid division by zero.\n\nIn the next section we use an example to define a Group. This will help develop an intuition on when we call a set of numbers a Group.\n\n### [Generator of a Group](#generator-of-a-group)\nA generator is an element within a group that, when combined with itself repeatedly through the group's operation, can eventually produce every other element within the group. \n\nIn mathematical sense, if you have a group ($\\mathbb G, .)$ and an element $g$ in $\\mathbb G$ we say that $g$ is a generator of $\\mathbb G$ if the set of all powers of $g$, $(g, g^2, g^3, ...)$, is equal to $\\mathbb G$ for a finite group, or covers all elements of $\\mathbb G$ through this repeated operation in the case of an infinite group.\n\nThis concept is best explained with an example.\n\nWe will work with ($\\mathbb G_7, +)$ of group elements { ${0,1,2,3,4,5,6}$ } and ($\\mathbb G^*_7, .)$ of group elements { ${1,2,3,4,5,6}$ } with modulo $7$ to find the generator of the Groups.\n\n**Generator of Additive Group**\n\nOur set ($\\mathbb G_7, +)$ with elements { ${0,1,2,3,4,5,6}$ } is a Group because it satisfies the definition of a Group.\n\n- **Closure:** When you add any two numbers in the set and take the remainder when divided by $7$, you end up with a result that's still in the set.\n- **Associativity:** For any numbers $a, b$ and $c$ in the set, $(a+b)+c$ is always the same as $a+(b+c)$, even with modulo $7$.\n- **Identity element:** The number $0$ acts as an identity element because when you add $0$ to any number in the set, you get the same number back.\n- **Inverse elements:** Every number in the set has an inverse such that when you add them together, you end up back at the identity element $0$. For example, the inverse of $3$ is $4$ because $3 + 4 = 7$, which is $0$ modulo $7$.\n\nNow, for the generator. Since our group has a prime order $7$, any element except for the identity element $0$ is a generator. Let's pick the element $1$ as our generator i.e $g = 1$. Since we are working with an additive group, our group elements with generator g will be $\\{0, g, 2g, 3g, 4g, 5g, 6g\\}$.\n\n\nStarting with $1$ and adding it to itself modulo $7$, we get:\n- $1 + 1 = 2$ (which is $2*1$ modulo 7)\n- $1 + 1 + 1 = 3$ (which is $3*1$ modulo 7)\n- $1 + 1 + 1 + 1 = 4$ (which is $4*1$ modulo 7)\n- $1 + 1 + 1 + 1 + 1 = 5$ (which is $5*1$ modulo 7)\n- $1 + 1 + 1 + 1 + 1 + 1 = 6$ (which is $6*1$ modulo 7)\n- $1 + 1 + 1 + 1 + 1 + 1 + 1 = 7$, which is $0$ modulo 7 (which is $7*1$ modulo 7)\n\nAs you can see, by repeatedly adding $1$ modulo $7$, we can generate every other element in the group. Hence, $1$ is a generator of the group ($\\mathbb G_7, +)$. Similarly, we could pick any number in $2, 3, 4, 5, 6$ as our generator, and by performing repeated addition modulo $7$, we would still generate the entire group. This is a special property of groups with a prime number of elements.\n\n\n**Generator of Multiplicative Group**\nFor the multiplicative group of integers modulo a prime $p$, the group ($\\mathbb G_p, .$) consists of the integers { ${1, 2, 3, \\ldots, p-1}$ }, where the operation is multiplication modulo $p$. We'll choose a small prime to make it simple, say $p = 7$. So, our group ($\\mathbb G^*_7, .)$ under multiplication modulo $7$ consists of the elements { ${1, 2, 3, 4, 5, 6}$ }. Remember, division by zero element is excluded, that's why we have `*` in the notation.\n\nHere's the group structure:\n\n- **Closure:** The product of any two elements, when reduced modulo $7$, is still an element of the set.\n- **Associativity:** For any numbers $a, b, c$ in the set, $(a \\cdot b) \\cdot c$ is always the same as $a \\cdot (b \\cdot c)$, even when considering modulo $7$.\n- **Identity element:** The number $1$ acts as an identity element because when you multiply any number in the set by $1$, you get the same number back.\n- **Inverse elements:** Every number in the set has a multiplicative inverse in the set such that when you multiply them together, you get the identity element $1$. For example, the multiplicative inverse of $3$ is $5$ because $3 \\cdot 5 = 15$, which is $1$ modulo $7$.\n\nLet's verify that each element is indeed a generator by multiplying it repeatedly modulo $7$:\n\n- Starting with $2$, we multiply by $2$ each time and take the result modulo $7$:\n - $2^1 = 2$\n - $2^2 = 4$\n - $2^3 = 8 \\equiv 1 \\mod 7$\n - $2^4 = 16 \\equiv 2 \\mod 7$ (and here we cycle back to the beginning, showing that $2$ is not a generator)\n\n- Let's try $3$:\n - $3^1 = 3$\n - $3^2 = 9 \\equiv 2 \\mod 7$\n - $3^3 = 27 \\equiv 6 \\mod 7$\n - $3^4 = 81 \\equiv 4 \\mod 7$\n - $3^5 = 243 \\equiv 5 \\mod 7$\n - $3^6 = 729 \\equiv 1 \\mod 7$ (and since we've reached the identity after hitting all elements, $3$ is a generator)\n\nYou can verify that $5$ is also a generator for our multiplicative group ($\\mathbb G^*_7, .)$ modulo $7$. \n\n### [Why Primes for Modulo Operations in Fields](#why-primes-for-modulo-operations-in-fields)\nChoosing a prime number as the modulus for operations in a finite field offers several benefits and simplifies various aspects of field arithmetic:\n\n1. **Well-defined Division:** In a finite field, every non-zero element must have a multiplicative inverse. If the modulus is prime, every number in the set { ${1, 2, 3, \\ldots, p-1}$ } has a multiplicative inverse modulo $p$. This property allows for well-defined division operations within the field, which wouldn't be possible if the modulus wasn't prime (except in special cases like Galois fields of order $p^n$, where $p$ is prime).\n\n2. **Simplicity of Construction:** When the modulus is a prime number, the field's construction is straightforward. The elements of the field are simply the set of integers { ${1, 2, 3, \\ldots, p-1}$ }, and the field operations (addition, subtraction, multiplication, and division) are performed modulo $p$. For non-prime moduli, constructing a field requires more complex structures, such as polynomial rings.\n\n3. **Guaranteed Field Properties:** The use of a prime modulus guarantees the satisfaction of required field properties. These include - the existence of additive and multiplicative identities, the existence of additive and multiplicative inverses for every element, and the commutative, associative, and distributive laws for addition and multiplication. A prime modulus ensures all these properties are met.\n\n4. **Uniform Distribution of Non-zero Elements:** In a finite field with a prime modulus, the non-zero elements have a uniform distribution with respect to multiplication. This means that the multiplication table of the field does not have any 'gaps' and every element appears exactly once in each row and column of the multiplication table (except the row and column for the zero element).\n\n5. **Simplified Algorithms:** Many algorithms in number theory and cryptography are simpler and more efficient when working with prime fields. For example, finding multiplicative inverses can be done efficiently using the Extended Euclidean Algorithm, and there's no need for complex polynomial arithmetic that is necessary in non-prime fields.\n\n6. **Cryptographic Security:** In the context of cryptography, the difficulty of certain problems, such as the discrete logarithm problem, is well-understood in prime fields. This difficulty is crucial for the security of cryptographic systems. For composite moduli (especially when the factors are not known), the structure can introduce vulnerabilities or make the problem's difficulty less predictable.\n7. **Optimization in Computation:** Some prime numbers, like 31 or primes of the form $2^n - 1$, are easily optimized by CPUs for multiplication operations. This optimization can lead to faster computation times, which is beneficial in applications where performance is a critical factor.\n\nUsing a prime number as the modulus for finite fields simplifies the field arithmetic and ensures that all field properties are satisfied, which is essential for both theoretical and practical applications, particularly in cryptography.\n\n\n### [Cryptographic Assumptions](#cryptographic-assumptions)\nIn order to work with KZG commitment scheme, we need two additional assumptions. We won't go deep into why these assumptions are needed but we will give an intuition to why these cryptographic assumptions are needed to make KZG more secure.\n\n**Discrete Logarithm**\n\nSay we have a generator $g$ in the group $\\mathbb G^\\*_p$ and $a$ is any element in the finite field $\\mathbb F^*_p$ and $g^a$ is some element in the group $\\mathbb G^\\*_p$. The Discrete Logarithm assumption says that it is practically impossible to find $a$, for given $g$ and $g^a$. This means we can't easily find the exponent $a$ that will give us these elements.\n\n**Developing an intuition for Discrete Logarithm Problem**\n\nImagine you have a special kind of lock that works with numbers (let's call this lock a \"generator\", and we'll name it $g$). This lock is part of a magic set of locks and keys, all living in a magical land called $\\mathbb G^\\*_p$. Now, you pick a secret number $a$ and use it to turn your lock $g$ a certain number of times. The lock ends up in a new position, let's call this $g^a$.\n\nIf someone walks by and sees your lock at $g^a$, even if they know it started at $g$ and the magical land it belongs to, figuring out how many times you turned it (finding your secret number $a$) is incredibly difficult. \n\nIn simpler terms, the Discrete Logarithm problem tells us that even though it's easy to turn the lock around if you know your secret number, going backwards — seeing the result and trying to guess the secret number — is like finding a needle in a haystack. This concept is crucial in cryptography, ensuring that some secrets are incredibly hard to uncover.\n\n**Strong Diffie-Hellman**\n\nSay we have a generator $g$ in the group $\\mathbb G^\\*_p$ and $a, b$ are any elements in the finite field $\\mathbb F^*_p$ and $g^a$, $g^b$ are some elements in the group $\\mathbb G^\\*_p$. The Strong Diffie-Hellman assumption says that $g^a$ and $g^b$ are indistinguishable from $g^{ab}$. This means we can't extract any extra information about $g^{ab}$ given $g^a$ and $g^b$.\n\n\n**Developing an intuition for Strong Diffie-Hellman**\n\nImagine you're in a world, famous for its magical cookies, and there's a secret ingredient (our \"generator\", $g$) that makes them special. Two master bakers, Alice and Bob, each know a unique twist to using this ingredient, represented by their own secret recipes $a$ and $b$, respectively.\n\nWhen Alice bakes her cookies using her secret recipe, she creates a special batch $g^a$. Bob does the same with his recipe, resulting in another unique batch $g^b$.\n\nNow, suppose Alice and Bob decide to collaborate and combine their secret recipes to create a super-secret batch of cookies $g^{ab}$. The Strong Diffie-Hellman assumption is saying that even if someone has tasted both Alice's and Bob's individual batches, they can't decipher what their combined super-secret batch would taste like. The flavors of the combined recipe are indistinguishable from any other batch without knowing the exact combination of Alice's and Bob's recipes.\n\nSo, in essence, the Strong Diffie-Hellman assumption tells us that just knowing the outcomes of individual secrets (recipes) doesn't help anyone crack the result of combining those secrets. This is a cornerstone of secure communication, ensuring that even if someone knows the separate pieces, the combined secret remains safe and unguessable.\n\n\n### [Pairing Function](#pairing-function)\nSay we have a generator $g$ in the group $\\mathbb G^\\*_p$ and $a, b$ are any elements in the finite field $\\mathbb F^*_p$ and $g^a$, $g^b$ are some elements in the group $\\mathbb G^\\*_p$. \n\nA pairing function is a mathematical function that takes two inputs and produces a single output by mapping distinct pairs of inputs to a distinct value. It has two important properties, bilinearity and non-degeneracy. \n\n- Bilinearity means, we can move around in a reversible way. \n- Non-degeneracy means, if we apply pairing function to the same element, it doesn't result in the identity element of the Group.\n\nLet's define these properties a bit more rigorously.\n\nA pairing function $e:$ $\\mathbb G_1 X \\mathbb G_2 \\rightarrow \\mathbb G_T$ such that it satisfies,\n\nBilinear property: $e(g^a, g^b) = e(g, g^{ab}) = e(g^{ab}, g) = e(g,g)^{ab}$\n\nNon-degenerate property: $e(g,g) \\neq 1$, means the output is not an identity element.\n\nWhen $\\mathbb G_1$ and $\\mathbb G_2$ are the same Group, we call this symmetric pairing function. Otherwise, it is an asymmetric pairing function. \n\nHere are some great resources to learn more about pairing functions from a practical POV[^3][^8][^9].\n\n**Developing an intuition for Pairing function**\n\nImagine two separate islands, each inhabited by a unique species of magical creatures. The first island is home to Unicorns, each with a distinct color, and the second island is inhabited by Dragons, each with a unique fire color. A pairing function is like a magical bridge that connects a Unicorn with a Dragon, creating a unique, new magical creature, a Dracorn, that embodies characteristics of both.\n\nHere's how to think about this pairing function without getting bogged down by technicalities:\n\n- **Two Groups:** Think of the Unicorns and Dragons as belonging to two different groups (in mathematical terms, these are usually called groups $\\mathbb G_1$ and $\\mathbb G_2$).\n- **Pairing Function:** The magical bridge acts as the pairing function. When a Unicorn and a Dragon meet on this bridge, the pairing function combines them into a Dracorn. This Dracorn has a special glow that uniquely corresponds to the combination of that specific Unicorn and Dragon (reversible).\n- **Unique Outcome:** Just like every Unicorn and Dragon pair produces a Dracorn with a unique glow, in mathematics, a pairing function takes one element from each group and produces a unique output in a third group (often denoted as $\\mathbb G_T$).\n\n**Why is this magical?** Because even though there are countless possible combinations of Unicorns and Dragons, each combination (pairing) produces a unique Dracorn. This is powerful in cryptography because it allows for complex operations that underpin many security protocols, ensuring that each combination is distinct and traceable to its original pair.\n\n**In simpler terms,** imagine you have two sets of keys (Unicorns and Dragons), and when you combine one key from each set, you get a unique lock (Dracorn). The magic is in how predictable yet secure this combination is, allowing for secure interactions that rely on the certainty of these unique outcomes without revealing the original keys.\n\nPairing functions enable advanced cryptographic techniques, such as those used in certain types of digital signatures and encryption, by allowing this kind of \"cross-group\" interaction to occur securely and predictably.\n\n## [Properties of Commitments](#properties-of-commitments)\nCommitment schemes are like the secret-keeping wizards of the digital world. They let someone make a promise about a piece of information (we'll call this the secret message) in a way that ties them to their promise without letting anyone else know what the secret is. Here's how it works:\n\n- **Making the Promise (Commitment):** You decide on a secret message and use a special spell (the commitment scheme) to create a magic seal (the commitment). This seal proves you have a secret, but it keeps the secret hidden.\n- **Keeping It Secret (Hiding):** Even though you've made this seal, nobody else can see what your secret message is. It's like you've locked it in a chest and only you have the key.\n- **Proving You're Honest (Binding):** The magic of the commitment is that you can't change your secret message later without breaking the seal. This means once you've made your commitment, you're bound to it.\n\nLater, when the time comes to reveal your secret, you can show the original message and prove that it matches the seal you made before. This lets someone else (the Verifier) check and confirm that your secret message is the same one you committed to in the beginning, proving that you kept your word.\n\nThe Binding and Hiding properties are extremely important and they tie back to the above cryptographic assumptions we made with the Discrete Logarithm and Strong Diffie-Hellman assumptions.\n\nBut for now, we don't need to go deep into the technicalities. In case, you want to learn more, here is a great resource for PCS from Prof. Dan Boneh[^4].\n\nWith this background, we are ready to explain KZG protocol flow and understand its construction.\n\n\n## [KZG Protocol Flow](#kzg-protocol-flow)\nLet us reiterate on what is the problem we are solving with KZG protocol.\n\nWe want prove that we know a specific evaluation of a function or polynomial at a point $x=a$ without revealing it.\n\nIn the KZG commitment scheme, the roles of the Trusted Third Party, Prover, and Verifier are critical to its function and security. Here's how each contributes to the process:\n\n1. **Trusted Third Party (Setup Authority):** This entity is responsible for the initial setup phase of the KZG scheme. They generate the public parameters (PP) or Common Reference String (CRS) that will be used in the commitments and proofs, based on a secret that only they know. This secret is crucial for the construction of commitments but must be discarded (or kept extremely secure) after the setup to ensure the system's integrity. The trust in this party is fundamental because if the secret is mishandled or leaked, it could compromise the entire system. The role of this party concludes once they have generated the CRS and distributed it to both the Prover and the Verifier. After this point, they are not involved in any further steps of the protocol, whether it be in proving or verifying.\n\n2. **Prover:** The Prover is the one who wants to commit to a certain piece of data (like a polynomial) without revealing it. Using the CRS provided by the Trusted Third Party, the Prover computes a commitment to their data. When it's time to prove certain properties of their data (like a polynomial evaluation at a specific point), the Prover can generate a proof based on their commitment. This proof shows that their data has certain properties without revealing the data itself.\n\n3. **Verifier:** The Verifier is the party interested in checking the Prover's claims about their secret data. The Verifier uses the proof provided by the Prover, along with the CRS from the Trusted Third Party, to verify that the Prover's claim about their data is true. This is done without the Verifier ever directly accessing the secret data. The strength of the KZG scheme ensures that if the proof verifies correctly, the Verifier can be confident in the Prover's claim, assuming the Trusted Third Party has correctly performed their role and the secret has not been compromised.\n\nThis interaction between the three parties allows for secure and efficient verification of data properties in a variety of cryptographic applications, including blockchain protocols and secure computation, providing a balance between transparency and privacy.\n\nBelow is a detailed sequence diagram that explains the flow in a typical KZG protocol.\n\n```mermaid\nsequenceDiagram\n autonumber\n participant TP as Trusted Party\n Actor P as Prover \n Actor V as Verifier\n\n rect rgb(255, 190, 152)\n note right of TP: Generates a ∈ F_p,
computes PP =
and DELETES a \n TP->>P: Sends PP\n TP->>V: Sends PP\n rect rgb(128,182,223)\n note right of P: P Chooses f(x) ∈ F_p[X] and computes C_f = C(f(a)) = f(a).g ∈ F_p using PP.\n P->>V: Sends C_f\n V-->>P: V Asks to open at b ∈ F_p\n rect rgb(224,128,135)\n note right of P: P Computes Q_b(x) = (f(x) - f(b)) / (x - b) and computes C_Q = C(Q_b) = Q_b(a).g.\n P->>V: Sends (b, f(b), C_Q)\n V->>P: Checks if e(C_f - f(b).g, g) == e(C_Q, ag - bg)\n end\n end\n end\n```\n\n### [Trusted Setup](#trusted-setup)\nA trusted third party picks a random element $a \\in \\mathbb{F}_p$. They compute the public parameter (PP) or common reference string (CRS), as < $g, {a^1}.g, {a^2}.g, \\ldots, {a^t}.g$ >. Then, they **delete** $a$. This step of deleting $a$ is extremely important to secure the system.\n\nThen, the trusted party sends the CRS to the Prover and the Verifier.\n\nIn practice, this process is wrapped around a multi-party computation (MPC) where a secret is generated in such a way that, as long as at least one participant remains honest, the randomness of the secret can be guaranteed. \n\nThe trusted setup is a one-time procedure that generates a piece of data necessary for the cryptographic protocol to function. This data must be used every time the protocol is run, but once generated and the secrets are forgotten, no further participation from the creators of the ceremony is required. The trust in the setup comes from the fact that the secrets used to generate the data are securely discarded after the setup, ensuring that the data remains secure for future use.\n\nModern protocols often use a powers-of-tau setup, which involves even thousands of participants. The security of the final output depends on the honesty of at least one participant who does not publish their secret. This approach is considered \"close enough to trustless\" in practice, making it a practical solution for cryptographic protocols that require a trusted setup. \n\nEthereum has a very detailed documentation of the Trusted Setup ceremony for more detail[^2].\n\n### [Initial Configuration](#initial-configuration)\nSay the Prover has a function or polynomial $f(x)$ defined as $f(x) = f_0 + f_1x + f_2x^2 + \\ldots + f_dx^t$ in a finite field $\\mathbb F_p$. The degree of $f(x)$ is $t$ which is less than $p$, the order of the finite field $\\mathbb F_p$.\n\nWe often denote this as $f(x) \\in \\mathbb{F}_p[x]$.\n\n$\\mathbb{G}_p$ is an Elliptic Curve group of order $p$ with a generator $g$.\n\nOften, the prime order $p$ is chosen such that $p \\gt 2^k$, for some security parameter k. The prime number $p$ is very large in practice.\n\nProver also picks a pairing function that satisfies both bilinear and non-degenerate properties. The pairing is denoted as below:\n\n$e:$ $\\mathbb G_1 X \\mathbb G_2 \\rightarrow \\mathbb G_T$ \n\nTo simplify this step, Prover picks a polynomial $f(x) \\in \\mathbb{F}_p[x]$, the degree of $f(x)$ is at most $t$ which is less than $p$, the order of the finite field $\\mathbb{F}_p$. Prover also picks a pairing function $e$ on the Elliptic Curve group $\\mathbb{G}_p$.\n\n\n### [Commitment of the Polynomial](#commitment-of-the-polynomial)\nSay, the commitment of the polynomial $f(x)$ is denoted as $C_f$. The commitment is like hash function. \n\nSo $C_f = {f(a)} \\cdot g = {(f_0 + f_1a + f_2a^2 + \\ldots + f_ta^t)} \\cdot g$. Here $f(a)$ is the polynomial evaluated at $x=a$.\n\nThough, the Prover doesn't know $a$, he or she can still compute the commitment of the polynomial at $x=a$.\n\nSo we have, $C_f = {f(a)} \\cdot g = {(f_0 + f_1a + f_2a^2 + \\ldots + f_ta^t)} \\cdot g$.\n\n$C_f = {f_0} \\cdot g + {f_1a} \\cdot g + {f_2a^2} \\cdot g + \\ldots + {f_ta^t} \\cdot g $.\n\n$C_f = {f_0} \\cdot g + {f_1} \\cdot (ag) + {f_2} \\cdot ({a^2}g) + \\ldots + {f_t} \\cdot ({a^t}g)$.\n\nFrom the CRS, the Prover knows these values < $g, {a^1}.g, {a^2}.g, \\ldots, {a^t}.g$ >, he or she can compute this value as commitment of the polynomial, $C_f$ and sends to the Verifier.\n\n### [Opening of the Polynomial](#opening-of-the-polynomial)\nUpon receiving a commitment to a polynomial, denoted by $C_f$, from the Prover, the Verifier takes the next step in the protocol by selecting a random point, which we'll call $b$, from the field $\\mathbb F_p$. The Verifier then requests the Prover to open or reveal the value of the polynomial at this specific point.\n\n**What does 'opening the polynomial' mean?**\nOpening the polynomial at $x=b$ involves calculating the value of the polynomial at that point, which is mathematically represented as $f(b)$. This is done by evaluating the polynomial using the chosen point $b$:\n\n$f(b) = f_0 + f_1b + f_2b^2 + \\ldots + f_tb^t$.\n\nLet's assume that this computation results in $f(b) = d$. The Prover's task is now to provide the Verifier with an Evaluation Proof, which is evidence that $f(b)$ truly equals $d$.\n\nLet's unpack this step by step. \n\n**Calculating the Evaluation Proof:**\nThe Prover determines the Quotient polynomial, which we will denote as $Q(x)$, and computes a commitment to it. This step is essential for creating a verifiable proof. Since we know $f(b)=d$, the polynomial $(f(x)−d)$ will have a root at $x=b$, meaning that $(f(x)−d)$ is divisible by $x−b$ with no remainder—this is a consequence of Little Bezout’s Theorem[^1].\n\nExpressed in mathematical terms, the Quotient polynomial is:\n$Q(x) = \\frac{f(x) - f(b)}{x - b} = \\frac{f(x) - d}{x - b}$\n\nThe commitment to the Quotient Polynomial, $Q(x)$, is represented by $C_Q$. Using the Common Reference String (CRS) provided during the Trusted Setup, the Prover calculates $C_Q$:\n$C_Q = {Q(a)} \\cdot g$.\n\nThe Prover can calculate $C_Q$ as long as $(f(x) - f(b))$ is divisible by $(x−b)$. If this were not the case, $Q(x)$ would not be a proper polynomial i.e. the Quotient polynomial will have a denominator and some negative exponents, and the Prover could not compute the Evaluation Proof $C_Q$ using only the CRS.\n\nFinally, the Prover sends the tuple < $b, f(b), C_Q$ > to the Verifier, completing this stage of the protocol.\n\n\n### [Verification Proof](#verification-proof)\nLet's first summarize what data does the Verifier has so far in the protocol. \n\n**Data in hand:** The Verifier knows:\n- The commitment of the polynomial, $C_f$.\n- The opening point $b$.\n- The value of the polynomial at $b$, denoted as $f(b)$.\n- The commitment to the Quotient polynomial at $b$, denoted as $C_Q = {Q(a)} \\cdot g$.\n\n**Properties of a commitment scheme:**\n- **Completeness:** A commitment scheme is said to be **complete** if anything which is true is provable. \n- **Soundness:** It is said to be **sound** if everything which is provable is true - i.e. anything which is false cannot be proven by the scheme.\n\n**Quotient polynomial and verification:**\n\nRecall that the Quotient polynomial is given by\n$Q(x) = \\frac{f(x) - f(b)}{x - b} = \\frac{f(x) - d}{x - b}$.\n\nSo, $(x - b) \\cdot Q(x) = f(x) - d$\n\nEvaluating this at $x=a$, we get\n$(a - b) \\cdot Q(a) = f(a) - d$\n\nMultiplying both sides by the generator $g$, we get\n\n$(a−b) \\cdot Q(a) \\cdot g = f(a) \\cdot g − d \\cdot g$\n\nNow, the Verifier knows that $C_Q = Q(a) \\cdot g$ and $C_f = f(a) \\cdot g$.\n\nSo substituting, we get\n\n$(a−b) \\cdot C_Q = C_f − d \\cdot g$\n\nIf the verifier can confirm the validity of the above equality, it means the commitment has been verified. However, since the verifier is unaware of the value of $a$, they cannot directly validate the truth of this equality.\n\nHowever, the Verifier can use Elliptic Curve Pairings as outlined above to verify the equality constraint even without knowing $a$. Remember that the pairing function is denoted as:\n\n$e:$ $\\mathbb G_1 X \\mathbb G_2 \\rightarrow \\mathbb G_T$ such that it satisfies,\n\nBilinear property: $e(g^a, g^b) = e(g, g^{ab}) = e(g^{ab}, g) = e(g,g)^{ab}$\n\nNon-degenerate property: $e(g,g) \\neq 1$, means the output is not an identity element.\n\nLet us for now, use a symmetric pairing function where $e:$ $\\mathbb G X \\mathbb G \\rightarrow \\mathbb G_T$ \n\nThe Prover has to check he equality $(a−b) \\cdot C_Q = C_f − d \\cdot g$.\n\nThe pairing function takes any two elements from the group $\\mathbb G$ and maps it to an element in $\\mathbb G_T$. \n\n- A commitment, like $C_f$ or $C_Q$, is obtained by multiplying a number (a scalar) with the group's generator, $g$.\n- Since both $C_f$ and $C_Q$ are the result of this operation, they belong to the group $\\mathbb G$.\n- When we multiply $C_Q$ by the difference of two numbers $a$ and $b$, which is also a scalar, the result, $(a−b) \\cdot C_Q$, stays within the group $\\mathbb G$.\n- Similarly, $C_f$ is a group element, and so is $d \\cdot g$ because it's the generator multiplied by a scalar.\n- Subtracting $d \\cdot g$ from $C_f$ gives us another element in the group, $C_f − d \\cdot g$.\n- All these resulting elements are part of the group $\\mathbb G$ and can be used in the pairing function.\n\nSo, applying the pairing function on the both sides using the generator $g$ as the second parameter, the equality constraint becomes, \n\n$e((a−b) \\cdot C_Q, g) = e(C_f − d \\cdot g, g)$\n\nWe still can't calculate $a-b$ as nobody knows $a$. But we can use the bilinear property of the pairing function \n\n$e(g^a, g^b) = e(g, g^{ab}) = e(g^{ab}, g) = e(g,g)^{ab}$\n\nSo we can rewrite the equality constraint as\n\n$e(C_Q, (a−b) \\cdot g) = e(C_f − d \\cdot g, g)$\n\n$e(C_Q, a \\cdot g − b \\cdot g) = e(C_f − d \\cdot g, g)$\n\nThough the Verifier doesn’t know $a$, he or she knows $a \\cdot g$ from the Common Reference String. So now the Verifier can check whether the above equality is true or not. This ends the verification of the Evaluation Proof.\n\n**Full Opening VS Partial Opening of the polynomial**\n\n- **Full Open Process:**\n - The Prover sends the complete polynomial to the Verifier.\n - Using the CRS, the Verifier independently computes the polynomial's commitment.\n - The Verifier then checks if this independently computed commitment matches the one originally sent by the Prover.\n\n- **Partial Open Process in KZG:**\n - Instead of opening the whole polynomial, the Prover can opt for a partial open.\n - This means the Prover reveals the polynomial's value at a single specific point.\n - This partial revelation is known as the Evaluation Proof.\n\n## [KZG by Hands](#kzg-by-hands)\nNow, let us practically derive the steps in KZG protocol using a small finite field. We can compute all finite field operations and pairing operations by hand and get a feel for the KZG protocol flow and verifying polynomial commitments.\n\n### [KZG by Hands - Initial Configuration](#kzg-by-hands---initial-configuration)\n- We will work with the finite field $(\\mathbb F_{11}, + )$. So, the prime order $p = 11$. This means all finite field operations are done modulo 11. \n- The finite field set is {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10}. \n- The generator $g = 2$ in $(\\mathbb G_{11}, +)$. \n- This means that the group operation is addition with modulo 11.\n- The Prover selects the polynomial $f(x) = 3x^2 + 5x + 7$. \n- Then we have the degree of the polynomial $f(x)$ as $t = 2$.\n- The pairing function $e(x, y) = xy$ over $(\\mathbb G_{11}, +)$.\n\n### [KZG by Hands - Trusted Setup](#kzg-by-hands---trusted-setup)\n- The Trusted Party chooses a secret number randomly. Say, $a = 3$ is the secret number.\n- They generate the public parameter or the common reference string (CRS) < $g, {a^1}.g, {a^2}.g, \\ldots, {a^t}.g$ >.\n- This is equal to < $2, 3 \\cdot 2, {3^2} \\cdot 2$ > which is equal to < $2, 6, 7$ > after applying modulo 11.\n- The Trusted Party **deletes** the secret number $a$.\n- The Trusted Party sends the CRS to the Prover and Verifier. \n\n### [KZG by Hands - Commitment of the polynomial](#kzg-by-hands---commitment-of-the-polynomial)\n- The Prover calculates the commitment of the polynomial, $C_f$.\n- $C_f = f(a) \\cdot g = {f_0} \\cdot g + {f_1} \\cdot (ag) + {f_2} \\cdot ({a^2}g) $.\n- $C_f = 7 \\cdot g + 5 \\cdot (ag) + 3 \\cdot a^2g = 7.2 + 5.6 + 3.7 = 65 = 10$ (mod 11).\n- The Provers sends the commitment of the polynomial $C_f = 10$ to the Verifier.\n\n### [KZG by Hands - Opening of the Polynomial](#kzg-by-hands---opening-of-the-polynomial)\n- The Verifier asks the Prover to open the polynomial at $x = 1$.\n- The Prover computes the Quotient polynomial $Q(x) = \\frac{f(x) - f(1)}{x - 1} = \\frac{f(x) - d}{x - b}$.\n- Compute $f(1) = d = 3.1^2 + 5.1 + 7 = 4$ (mod $11$).\n- $Q(x) = \\frac{3x^2 + 5x + 7 - 4}{x - 1} = \\frac{3x^2 + 5x + 3}{x - 1}$.\n- Divide the Leading Term: $3x^2$ divided by $x$ gives us $3x$. We write $3x$ above the division bar.\n- Multiply the Divisor by the Quotient's Leading Term: Multiply $x - 1$ by $3x$ to get $3x^2 - 3x$.\n- Subtract from the Polynomial: Subtract $3x^2 - 3x$ from $3x^2 + 5x$ to get $8x$.\n- Bring Down the Next Term: Bring down the $+3$ to get $8x + 3$.\n- Divide the Next Term: $8x$ divided by $x$ is $8$. Write $+8$ above the division bar next to $3x$.\n- Multiply Again: Multiply $x - 1$ by $8$ to get $8x - 8$.\n- Subtract Subtract: $8x - 8$ from $8x + 3$ to get $11$.\n- Apply Modulo $11$: We reduce each term modulo $11$. Since $11$ is $0$ modulo $11$, the remainder is $0$.\n- The Prover computes the commitment of $C_Q = Q(a) \\cdot g = 3 \\cdot ag + 8 \\cdot g = 3.6 + 8.2 = 34 = 1$ (mod 11).\n- The Prover sends to the Verifier < $1, f(1), C_Q$ > = < $1, 4, 1$ >.\n\n### [KZG by Hands - Verification](#kzg-by-hands---verification)\n- The Verifier must check the pairing constraint $e(C_Q, a \\cdot g − b \\cdot g) = e(C_f − d \\cdot g, g)$\n- L.H.S (left hand side): $e(1, 6 - 1.2) = e(1, 4) = 1.4 = 4 (mod 11)$\n- R.H.S (right hand side): $e(10 - 4.2, 2) = e(2, 2) = 2.2 = 4 (mod 11)$.\n- This proves the equality constraint is true, hence the Evaluation Proof is verified.\n\n## [Security of KZG](#security-of-kzg)\n**Deleting toxic waste during the Trusted Setup Ceremony**\n\n- Imagine the Prover somehow finds out the secret number $a$ or the Trusted Party leaks $a$ to a malicious Prover.\n- The Prover computes $f_1(x) = 3x^2 + 5x + 7$ at $x=3$. So we get, $f_1(2) = 3.3^2 + 5.3 + 7 = 49 = 5 mod(11)$\n- The Prover computes $f_2(x) = 2x^2 + 7x + 10$ at $x=3$. So we get, $f_2(2) = 2.3^2 + 7.3 + 10 = 49 = 5 mod(11)$\n- This breaks the binding property of the commitment scheme leading to fraudulent proofs by the malicious Prover.\n- Hence, it is extremely important to **delete** the secret number $a$ by the Trusted Party after generating the CRS.\n\n## [Asymmetric Pairing Functions](#asymmetric-pairing-functions)\nAn asymmetric pairing function is denoted as:\n\n$e:$ $\\mathbb G_1 X \\mathbb G_2 \\rightarrow \\mathbb G_T$.\n\nLet the generators of $\\mathbb G_1$ be $g_1$ and $\\mathbb G_2$ be $g_2$. \n\nThe Prover has to check the equality $(a−b) \\cdot Q(a) = f(a) − d$.\n\nMultiplying both sides by $g_1$, we get\n\n$(a−b) \\cdot Q(a) \\cdot g_1 = f(a) \\cdot g_1 − d \\cdot g_1$\n\n$(a−b) \\cdot C_Q = C_f − d \\cdot g_1$\n\nApplying the asymmetric pairing function on both sides, we get\n\n$e((a−b) \\cdot C_Q, g_2) = e(C_f − d \\cdot g_1, g_2)$\n\nUsing the bilinear property, we get\n\n$e(C_Q, (a−b) \\cdot g_2) = e(C_f − d \\cdot g_1, g_2)$\n\n$e(C_Q, a \\cdot g_2 − b \\cdot g_2 ) = e(C_f − d \\cdot g_1, g_2)$\n\nHere $a \\cdot g_2$ will be the part of CRS of $\\mathbb G_2$ and everything else can be either computed or part of CRS of $\\mathbb G_1$.\n\n## [Unwavering Compactness](#unwavering-compactness)\nThe KZG Polynomial Commitment Scheme ensures that both commitments and evaluation proofs are of a fixed size, regardless of the polynomial's length, offering consistent and space-efficient cryptographic operations[^5][^6][^7].\n\nOne key benefit of the KZG Polynomial Commitment Scheme is its efficient use of space. No matter the length or complexity of the polynomial we're working with, the commitment to that polynomial—essentially its cryptographic \"footprint\"—is always a single, fixed-size element within a mathematical group, $\\mathbb G$. This means that as the polynomial grows in degree, the size of the commitment does not increase. The same principle applies to the evaluation proof, which is the evidence we provide to show that our commitment is accurate. Whether we're verifying just one value or many at once (in batch mode), the proof will always be of a consistent size. This consistency in size translates to predictable and efficient storage requirements, an important feature for practical applications in cryptography.\n\n## [KZG Batch Mode](#kzg-batch-mode)\nKZG commitments can also be opened and verified at multiple points or using multiple polynomials or any combination of them. This is called batch mode in practice.\n\n### [Single Polynomial, Multiple Points](#single-polynomial-multiple-points)\nIn batch mode, the Verifier requests the Prover to validate a set of points $B =$ { $b_1, b_2, b_3, \\ldots, b_n$ } with $n < t$, where $t$ is the degree of the polynomial $f(x)$. For these points, the Prover computes the values $f(b_1) = d_1, f(b_2) = d_2, \\ldots, f(b_n) = d_n$ and forms the set $D =$ { $d_1, d_2, d_3, \\ldots, d_n$ }.\n\nThe Prover then creates a Polynomial $P(x) = (x - b_1)(x - b_2)\\ldots(x - b_n)$. Given that $n < t$, it's possible to divide $f(x)$ by $P(x)$, resulting in $f(x) = P(x)Q(x) + R(x)$, where $Q(x)$ is the quotient polynomial and $R(x)$ is the remainder. This division suggests that $f(x)$ can be represented as such, not implying direct divisibility by $Q(x)$.\n\nThe commitment for $Q(x)$, denoted as $C_Q$, alongside the set $B$, is sent to the Verifier by the Prover. Optionally, the Prover may also send the remainder polynomial $R(x)$ to the Verifier. However, the Verifier has the capability to independently compute $R(x)$, considering that for any $b_i$ in $B$, $P(x)$ evaluates to zero, leading to $f(x) = R(x)$ for all $b_i$ in $B$.\n\nAs the degree of $Q(x)$ is $n$ and $R(x)$'s degree is less than $n$, the Verifier, knowing $R(x)$'s evaluation at $n$ points, can determine $R(x)$ via Lagrange’s Interpolation[^10].\n\nThe Verifier also computes the polynomials $P(x)$ and $R(x)$, alongside their commitments $C_P = P(a) \\cdot g$ and $C_R = R(a) \\cdot g$. They proceed to verify the Batch Evaluation by ensuring that $f(b_i) = R(b_i)$ for all $b_i$ in $B$ and that the equality $f(x) = P(x)Q(x) + R(x)$ holds.\n\nThe Verifier needs to evaluate the above constraint to verify the proof. However, since the secret opening at $x = a$ is unknown, hence she or he cannot evaluate it directly. But like before, the Verifier can use pairings to solve this.\n\nTo verify, the Verifier checks:\n- $f(b_i) = R(b_i)$ for each $b_i$ in $B$, comparing the Prover's provided $D$ values with their computation of $R(x)$ at each $b_i$.\n\n- The equality $f(x) \\cdot g - R(x) \\cdot g = P(x)Q(x) \\cdot g$ when evaluated at $x = a$, simplifying to $C_f - C_R = P(a) \\cdot C_Q$ using known commitments and the secret $a$.\n\nDespite not knowing $a$, the Verifier utilizes pairings to assess the proof:\n- Since both $C_f$ and $C_R$ belong to $\\mathbb G$, their difference does too.\n- Given $C_Q$'s membership in $\\mathbb G$ and $P(a)$ as a scalar, $P(a) \\cdot C_Q$ remains within $\\mathbb G$.\n\nApplying the pairing function yields:\n\n$e(C_f − C_R, g) = e(P(a) \\cdot C_Q, g)$\n\nApplying the bilinearity property, we get \n\n$e(C_f - C_R, g) = e(C_Q, C_P)$\n\nwhere $C_P = P(a) \\cdot g$. Given this, the Verifier can confirm the truth of the equality, thereby verifying the proof.\n\n\n## [References](#references)\n[^1]: https://en.wikipedia.org/wiki/Polynomial_remainder_theorem\n[^2]: https://github.com/ethereum/kzg-ceremony \n[^3]: https://www.rareskills.io/post/bilinear-pairing\n[^4]: https://www.youtube.com/watch?v=WyT5KkKBJUw\n[^5]: https://www.iacr.org/archive/asiacrypt2010/6477178/6477178.pdf \n[^6]: https://dankradfeist.de/ethereum/2020/06/16/kate-polynomial-commitments.html \n[^7]: https://www.youtube.com/watch?v=uGeIDNEwHjs&t=520s\n[^8]: https://www.youtube.com/watch?v=8WDOpzxpnTE \n[^9]: https://vitalik.eth.limo/general/2017/01/14/exploring_ecp.html\n[^10]: https://en.wikipedia.org/wiki/Lagrange_polynomial " }, { "path": "docs/wiki/Cryptography/bls.md", "content": "# Boneh-Lynn-Shacham (BLS) signature\n\n### TLDR;\n\n- Proof-of-stake protocols use digital signatures to identify their participants and hold them accountable.\n - Validators in Beacon chain (Ethereum) use BLS signatures to participate in Consensus, sign blocks, post attestations etc.\n- BLS signatures can be aggregated together, making them efficient to verify at large scale.\n- Signature aggregation allows the beacon chain to scale to hundreds of thousands of validators.\n- Normal Ethereum transaction signatures on the execution layer remain using ECDSA. However, account abstracted wallets can also utilize BLS.\n\nBLS is a digital signature scheme with aggregation properties. Given set of signatures (_signature_1_, ..., _signature_n_) anyone can produce an aggregated signature. Aggregation can also be done on secret keys and public keys. Furthermore, the BLS signature scheme is deterministic, non-malleable, and efficient. Its simplicity and cryptographic properties allows it to be useful in a variety of use-cases, specifically when minimal storage space or bandwidth are required. This page will cover the general idea and Math behind BLS signatures, further cover BLS in context of Ethereum.\n\n## How BLS works?\n\nAt the core of BLS signatures is the concept of bilinear mapping through pairings on elliptic curves. A key component is a pairing function $e$, defined between two groups derived from elliptic curves:\n\n$$e: G_1 \\times G_2 \\rightarrow G_T$$\n\nThis function is efficiently computable and must satisfy bilinear properties:\n\n- For all $P,Q$ in $G_1$ and $a$ in integers, bilinearity is defined as:\n $$e(aP, Q) = e(P, Q)^a$$\n $$e(P, aQ) = e(P, Q)^a$$\n\n- Additionally, it must distribute over addition:\n $$e(P + Q, R) = e(P, R) \\times e(Q, R)$$\n $$e(P, Q + R) = e(P, Q) \\times e(P, R)$$\n\nThese properties enable the cryptographic mechanisms necessary for functions like signature aggregation, which is a pivotal feature in blockchain applications and cryptographic consensus.\n\n#### Why BLS Over Schnorr and ECDSA for Digital Signatures?\n\nTraditional ECDSA signatures, as commonly used in Bitcoin or Ethereum transactions, depend heavily on the randomness of nonce generation and necessitate verification of all involved public keys individually, which can be computationally intensive. After its patent expired, Schnorr signatures became an alternative scheme which allows for some aggregation but still lacks the full efficiencies gained from BLS.\n\nBLS signatures, employing bilinear pairings, offer robust protection against certain cryptographic attacks and produce shorter signatures. Unlike Schnorr, BLS does not rely on random number generation for securing signatures, making it inherently more secure against randomness-related vulnerabilities.\n\n_Please note: While BLS signatures themselves do not require a random nonce for each signing operation (making them deterministic), the initial step of generating private keys in BLS is still dependent on secure random number generation. Unlike ECDSA, where a nonce is crucial in each signature to maintain security (and the randomness of this nonce is essential to prevent vulnerabilities), BLS avoids the need for this kind of nonce during the signing process. However, the randomness in generating the private key remains critical. This initial randomness ensures that the private key is secure and unpredictable, which is fundamental for the overall security of the cryptographic system._\n\n#### Example of BLS Signature Generation and Verification:\n\n
\n\n![Diagram showing key pair generation and verification for BLS](../../images/elliptic-curves/bls-alice.png)\n\n
\n\n_Visual Aid to understand how BLS signatures work_\n\n
\n
\n\nConsider Alice creating a BLS signature. She starts with her private key $a$, and computes her public key $P$ using a generator point $G$ on the elliptic curve:\n\n$$P = aG$$\n\nShe hashes her message and maps this hash to a point on the curve, $H(M)$. Her signature $S$ is then:\n\n$$S = a \\times H(M)$$\n\nThe signature is verified using the pairing function:\n\n$$e(G, S) = e(P, H(M))$$\n\nThis can be proven as:\n$$e(G,S)=e(G,a×H(m))=e(a×G,H(m))=e(P,H(M))$$\nwhere $G$ is the generator point on the elliptic curve.\n\nThis equation proves that the signature was indeed created by the holder of the private key corresponding to $P$.\n\n#### Example\n\nFor BLS signatures using a curve like BLS12-381 example values would look like:\n\n```\nMessage: \"Hello\"\nSecret Key: 26daf744780a51072aa8de191259bf7ff080b8457512cfd0eedfb4f8c71b131d\nPublic Key: bfdab807246849b76b7bdf5229619b9ccb33713633644a48b7ab3a7e67af7c1ae9d597a1c0fac6f61e63c1278b26c2f527be3d58bce95451b36f0c692ee90e1f\nSignature: dee15784b458419b4b8bbdbb13838da13c27dccab6ef50f0dcb4ff7352048c0b\n```\n\nFor ECDSA using a curve like secp256k1, there's an $R$ and an $S$ value, which produces a longer signature whose example values would look like:\n\n```\nMessage: \"Hello\"\nPrivate Key: 2aabe11b7f965e8b16f525127efa01833f12ccd84daf9748373b66838520cdb7\nPublic Key (EC Point):\n x: 39516301f4c81c21fbbc97ada61dee8d764c155449967fa6b02655a4664d1562\n y: d9aa170e4ec9da8239bd0c151bf3e23c285ebe5187cee544a3ab0f9650af1aa6\nSignature:\n R: 905eceb65a8de60f092ffb6002c829454e8e16f3d83fa7dcd52f8eb21e55332b\n S: 8f22e3d95beb05517a1590b1c5af4b2eaabf8e231a799300fffa08208d8f4625\n```\n\n### Aggregation in BLS:\n\nA major advantage of BLS is the ability to aggregate multiple signatures into a single compact signature. This is particularly useful in scenarios involving multiple transactions or signers, greatly reducing the blockchain space and computational power needed for verifications. For example if there are 100 transactions, where signature for each one is represented by $S_i$ and each are associated with a public key of $P_i$ (and a message $M_i$), rather than storing 100 separate signatures, BLS allows combining them into one:\n\n$$S = S_1 + S_2 + \\ldots + S_{100}$$\n\nwhich can then verified with (using a multiply operation):\n$$e(G,S)=e(P_1,H(M_1))⋅e(P_2,H(M_2))⋅…⋅e(P_{100},H(M_{100}))$$\n\nVerification of this aggregated signature would involve a corresponding aggregation of public keys and message hashes, maintaining the integrity and non-repudiation of all individual signatures.\n\n## BLS Signatures in Ethereum\n\nWith respect to Blockchain, digital signatures typically leverage elliptic curve groups. Ethereum primarily employs [ECDSA](/wiki/Cryptography/ecdsa.md) signatures using the [secp256k1](https://www.secg.org/sec2-v2.pdf) curve, while the beacon chain protocol adopts BLS signatures based on the [BLS12-381](https://hackmd.io/@benjaminion/bls12-381) curve. Unlike ECDSA, BLS signatures utilize a unique feature of certain elliptic curves known as \"[pairing](https://medium.com/@VitalikButerin/exploring-elliptic-curve-pairings-c73c1864e627).\" This allows for the aggregation of multiple signatures, enhancing the efficiency of the consensus protocol. While ECDSA signatures are [much quicker](https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-bls-signature-04#section-1.1) to process, the aggregative capability of BLS signatures offers significant advantages for blockchain scalability and consensus efficiency.\n\nThe process to create and verify a BLS signature is straightforward, involving a series of steps that can be explained through diagrams, descriptions, and mathematical principles, although understanding the mathematical detail is not essential for practical application.\n\nThere are **4** component pieces of data within the BLS digital signature process.\n\n- **The secret key:** Every participant in the protocol, specifically a validator, possesses a secret key, also referred to as a private key. This key is crucial for signing messages and maintaining the confidentiality of the validator's actions within the network.\n- **The public key:** Derived directly from the secret key using cryptographic methods, the public key, while linked to the secret key, cannot be reverse-engineered from it without extreme computational effort. It serves as the public identity of the validator within the protocol and is accessible to all participants.\n- **The message:** In Ethereum, messages consist of byte strings whose structure and purpose will be explored in further detail later in the context. Initially, understand these messages as basic data units processed within the blockchain protocol.\n- **The signature:** The signature is the result of the cryptographic process where the message is combined with the secret key. This signature uniquely identifies that a message was authored by the holder of the secret key. By verifying the signature with the corresponding public key, one can confirm that the message originated from a specific validator and has not been altered post-signing.\n\nIn Mathematical terms, we use 2 subgroups of BLS12-381 elliptic curve: $G_1$ defined over a base field $F_q$, and $G_2$ defined over the field extension $F_{q^2}$. The order of both the subgroups is $r$, a 77 digit prime number. The (arbitrarily chosen) generator of $G_1$ is $g_1$, and of $G_2$ is $g_2$.\n\n1. The secret key, $sk$, is a number between $1$ and $r$ (technically the range includes $1$, but not $r$. However, very small values of $sk$ would be hopelessly insecure).\n2. The public key, $pk$, is $[sk]g_1$ where the square brackets represent scalar multiplication of the elliptic curve group point. The public key is therefore a member of the $G_1$ group.\n3. The message, $m$ is a sequence of bytes. During the signing process this will be mapped to some point $H(m)$ that is a member of the $G_2$ group.\n4. The signature, $\\sigma$, is also a member of the $G_2$ group, namely $[sk]H(m)$.\n\n
\n\n![Diagram showing how we will depict the various components in the diagrams below.](../../images/elliptic-curves/bls-key.svg)\n\n
\n\n_The key to the keys. This is how we will depict the various components in the diagrams below. Variants of the same object are hatched differently. The secret key is mathematically a scalar; public keys are_ $G_1$ _group members; message roots are mapped to_ $G_2$ _group members; and signatures are $G_2$ group members._\n\n
\n
\n\n### Key pairs\n\nA key pair is a secret key along with its public key. Together these irrefutably link each validator with its actions.\n\nEach validator is equipped with at least 1 primary \"signing key\" used for routine operations like creating blocks, making attestations etc. Depending on their withdrawal credentials, a validator may also have a secondary \"withdrawal key,\" which is stored offline for added security.\n\nThe secret key should be randomly generated within the range $[1,r)$, adhering to the [EIP-2333](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-2333.md) standard, which recommends using the [`KeyGen`](https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-bls-signature-04#section-2.3) method from the draft IRTF BLS signature standard. Although compliance with this method is not mandatory, deviating from it is generally discouraged. Most stakers generate their keys using the [`eth2.0-deposit-cli`](https://github.com/ethereum/eth2.0-deposit-cli) tool from the Ethereum Foundation. For security, key pairs are typically stored in password-protected [EIP-2335](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-2335.md) keystore files.\n\nThe secret key, $sk$, is a 32-byte unsigned integer. The public key, $pk$, is represented as a point on the $G_1$ curve and serialized in a compressed format as a 48-byte string within the protocol.\n\n\n\n
\n\n![Diagram of the generation of the public key.](../../images/elliptic-curves/bls-setup.svg)\n\n
\n\n_A validator randomly generates its secret key. Its public key is then derived from that._\n\n
\n
\n\n### Signing in the Beacon Chain\n\nIn Ethereum's beacon chain, the only messages that get signed are the [hash tree roots](https://eth2book.info/capella/part2/building_blocks/merkleization/) of objects. These roots, called \"signing roots,\" are 32-byte strings. The [`compute_signing_root()`](/wiki/CL/functions#compute_signing_root) function integrates the hash tree root with a specific \"domain,\" enhancing the security.\n\n\n\nThe signing root is mapped onto an elliptic curve point within the $G_2$ group. This mapping, $H(m)$, where $m$ is the signing root, transforms the hash into a format suitable for cryptographic operations. This complex process is outlined in the [Hash-to-Curve draft standard](https://datatracker.ietf.org/doc/draft-irtf-cfrg-hash-to-curve/), but typically, developers rely on cryptographic libraries to manage this step efficiently.\n\n#### Signature Creation:\n\nThe actual signing involves multiplying the $G_2$ point $H(m)$ by the signer's secret key $sk$:\n\n$$\n\\sigma = [sk]H(m)\n$$\n\nThe signature $\\sigma$ thus generated is also part of the $G_2$ group and is typically compressed into a 96-byte string for practical use.\n\n
\n\n![Diagram of signing a message.](../../images/elliptic-curves/bls-signing.svg)\n\n
\n\n_A validator uses their secret key to sign a message, producing a unique digital signature_\n\n
\n\n
\n\n### Verifying Signatures\n\nTo validate a signature, the public key of the corresponding validator is necessary. This key is readily available in the beacon state, accessible by the validator's index, ensuring that key retrieval is straightforward and reliable.\n\nVerification is streamlined: input the message, public key, and signature into the verification process. If the signature is authentic—matching both the public key and the message—it is accepted; otherwise, it’s rejected due to potential corruption, incorrect key usage, or message tampering.\n\nFormally, this verification utilizes elliptic curve pairings. For the BLS12-381 curve, the pairing takes a point $P$ from $G_1$ and a point $Q$ from $G_2$, resulting in a point from group $G_T$:\n\n$$\ne: G_1 \\times G_2 \\rightarrow G_T\n$$\n\nPairings are expressed as $e(P, Q)$ and are crucial for validating the correspondence between the signature and the public key:\n\n$$\ne(g_1, \\sigma) = e(pk, H(m))\n$$\n\nThis checks whether the message signed with the secret key $sk$ matches the observed signature $\\sigma$, using the fundamental properties of [pairings](/wiki/Cryptography/bls#how-bls-works).\n\n
\n\n![Diagram of verifying a signature.](../../images/elliptic-curves/bls-verifying.svg)\n\n
\n\n_Verification uses the validator's public key and the original message to confirm the authenticity of the signature._\n\n
\n\n
\n\n**Verification Output**: The process returns `True` if the signature aligns with both the public key and the message, confirming its validity. If not, it returns `False`, indicating issues with the signature’s integrity or origin.\n\n## Resources and References\n\n- [BLS and key-pairing](https://asecuritysite.com/encryption/js_bls)\n- [BLS signatures and key-pairing concepts](https://www.youtube.com/watch?v=cVgJBdM5E2M)\n- [BLS aggregation by Vitalik Buterin and Justin Drake](https://www.youtube.com/watch?v=DpV0Hh9YajU)\n- [Pragmatic Signature Aggregation By Justin Drake](https://ethresear.ch/t/pragmatic-signature-aggregation-with-bls/2105?u=benjaminion)\n- [Building blocks from Eth2 Handbook](https://eth2book.info/capella/part2/building_blocks/signatures/)\n- [formal IETF Draft Standard](https://www.ietf.org/archive/id/draft-irtf-cfrg-bls-signature-05.html)\n- [Pairing Friendly curves](https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-pairing-friendly-curves-10)\n- [Hashing to elliptic curves](https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-hash-to-curve-09)\n- [ERC2333](https://github.com/ethereum/ercs/blob/master/ERCS/erc-2333.md) provides a method for deriving a tree-hierarchy of BLS12-381 keys based on an entropy seed.\n- [ERC2334](https://github.com/ethereum/ercs/blob/master/ERCS/erc-2334.md) defines a deterministic account hierarchy for specifying the purpose of keys.\n- [ERC2335](https://github.com/ethereum/ercs/blob/master/ERCS/erc-2335.md) specifies a standard keystore format for storage and interchange of BLS12-381 keys.\n" }, { "path": "docs/wiki/Cryptography/ecdsa.md", "content": "# A Brief Introduction to ECDSA\n\nIt is impossible to overstate how modern cryptography redefines trust for all our digital interactions - from securing bank account logins with encryption to verifying the authenticity of your favorite apps through digital certificates.\n\nPublic key cryptography is a key concept empowering these interactions. It consists of two key pairs:\n\n**Public key**: Widely distributed and used by anyone to verify an entity's identity.\n**Private key**: Confidential and known only to the owner, used for encryption and signing messages.\n\n**Elliptic curve cryptography (ECC)** is a specific type of public key cryptography that uses mathematics of elliptic curves to create smaller, and more efficient keys. This is especially beneficial in resource-constrained environments like Ethereum. Within Ethereum, the **Elliptic Curve Digital Signature Algorithm (ECDSA)** helps verify the legitimacy of submitted transactions.\n\nLet's consider a real-world scenario to understand how ECDSA works in action.\n\nAlice, a diligent businesswoman, has been abducted and held captive on a remote island. Her captors demand a hefty ransom of $1 million for her release. With limited options for communication, they provide a single postcard for her to instruct her associate, Bob, to transfer the funds.\n\nAlice considers writing the ransom amount and signing the postcard like a check. However, this method poses a significant risk: the kidnappers could easily forge the postcard, inflate the amount, and deceive Bob into sending them more money.\n\nAlice needs a robust approach that allows:\n\n1. Bob to verify that the transfer has be authorized by her, and\n2. ensure that postcard's message has not been tampered with.\n\nThe goal of this exercise is device a method for Alice to create a **secret key 🔑** known only to her. This key will be crucial for her to prove her identity and ensure the message's authenticity to Bob.\n\nMathematics, as always, comes to the rescue. Through ingenious use of **Elliptic Curves**, let's explore how Alice can generate the **secret key 🔑**.\n\n## Elliptic curves\n\nAn elliptic curve is a curve **described by the equation**:\n\n$$\ny^2 = x^3 + ax+b\n$$\n\nSuch that $4a^3 + 27b^2 \\ne 0$ to ensure the curve is non-singular.\nThe equation above is what is called the **Weierstrass normal form** of the long equation:\n\n$$\ny^2 + a_1 xy + a_3 y = x^3 + a_2 x^2 + a_4 x + a_6\n$$\n\nExamples:\n\n\n\nObserve that elliptic curves are symmetric about the x-axis.\n\nEthereum uses a standard curve known as [secp256k1](http://www.secg.org/sec2-v2.pdf) with parameters $a=0$, and $b=7$; which is the curve:\n$$y^2=x^3+7$$\n\n\n\n## Groups and Fields\n\n### Group\nIn mathematics, a **GROUP** is a set $G$, containing at least two elements, which is closed under a binary operation usually referred to as **addition** ($+$). A set is closed under an operation when the result of the operation is also a member of the set. \n\nThe set of real numbers $\\mathbb{R}$ is a familiar example of a group, since arithmetic addition of two real numbers is closed.\n\n$$\n 3 \\in \\mathbb{R}, 5 \\in \\mathbb{R} \\\\\n 3 + 5 = 8 \\in \\mathbb{R}\n$$\n\n## Field\nSimilarly, a **FIELD** is a set $F$, containing at least two elements, which is closed under two binary operations usually referred to as **addition** ($+$), and **multiplication**($\\times$). \n\nIn other words, A **FIELD** is a **GROUP** under both addition and multiplication.\n\nElliptic curves are interesting because the points on the curve form a group, i.e the result of \"addition\" of two points remains on the curve. This geometric addition, distinct from arithmetic counterparts, involves drawing a line through chosen points (**P** and **Q**) and reflecting the resulting curve intersection(**R'**) across the x-axis to yield their sum (**R**).\n\n
\n\n\nA point (**P**) can also be added to itself ($P+P$), in which case the straight line becomes a tangent to **P** that reflects the sum (**2P**).\n\n
\n\n\nRepeated point-addition is known as **scalar multiplication**:\n\n$$\nnP = \\underbrace{P + P + \\cdots + P}_{n\\ \\text{times}}\n$$\n\n## Discrete logarithm problem\n\nLet's leverage scalar multiplication to generate the **secret key 🔑**. This key, denoted by $K$, represents the number of times a base point $G$ is added to itself, yielding the resulting public point $P$:\n\n$$\nP = K*G\n$$\n\nGiven $P$ and $G$ it is possible derive the secret key $K$ by effectively reversing the multiplication, similar to the **logarithm problem**.\n\nWe need to ensure that scalar multiplication does not leak our **secret key 🔑**. In other words, scalar multiplication should be \"easy\" one way and \"untraceable\" the other way around.\n\nThe analogy of a clock helps illustrate the desired one-way nature. Imagine a task starting at 12 noon and ending at 3. Knowing only the final time (3) makes it impossible to determine the exact duration without additional information. This is because **modular arithmetic** introduces a \"wrap-around\" effect. The task could have taken 3 hours, 15 hours, or even 27 hours, all resulting in the same final time modulo 12.\n\n
\n\n\nOver a **prime modulus**, this is especially hard and is known as **discrete logarithm problem**.\n\n## Elliptic curves over finite field\n\nSo far, we have implicitly assumed elliptic curves over the rational field ($\\mathbb{R}$). Ensuring **secret key 🔑** security through the discrete logarithm problem requires a transition to elliptic curves over finite fields defined by a **prime modulus**. This essentially restricts the points on the curve to a finite set by performing modular reduction with a specific prime number.\n\nFor the sake of this discussion, we will consider the **secp256k1** curve defined over an **arbitrary finite field** with prime modulus **997**:\n\n$$\ny^2 = x^3 + 7 \\pmod {997}\n$$\n\n\n\nWhile the geometric representation of the curve in the finite field may appear abstract compared to a continuous curve, its symmetry remains intact. Additionally, scalar multiplication remains closed, although the \"tangent\" now \"wraps around\" given the modulus nature.\n\n
\n\n\n## Generating key pair\n\nAlice can finally generate a key pair using elliptic curve over finite field.\n\nLet's define the elliptic curve over the finite field of prime modulus 997 in [Sage.](https://www.sagemath.org/)\n\n```python\nsage: E = EllipticCurve(GF(997),[0,7])\nElliptic Curve defined by y^2 = x^3 + 7 over Finite Field of size 997\n```\n\nDefine the generator point $G$ by selecting an arbitrary point on the curve.\n\n```python\nsage: G = E.random_point()\n(174 : 487 : 1)\n```\n\nScalar multiplication over an elliptic curve defines a cyclic **subgroup of order $n$**. This means that repeatedly adding any point in the subgroup $n$ times results in the point at infinity ($O$), which acts as the identity element.\n\n$$\nnP = O\n$$\n\n```python\nsage: n = E.order()\n1057\n# Illustrating that n*G (or any point) equals O, represented by (0 : 1 : 0).\nsage: n*G\n(0 : 1 : 0)\n```\n\nA key pair consists of:\n\n1. **Secret key 🔑**($K$): A random integer chosen from the order of the subgroup $n$. Ensures only Alice can produce valid signatures.\n\nAlice randomly chooses **42** as the **secret key 🔑**.\n\n```python\nsage: K = 42\n```\n\n2. **Public key** ($P$): A point on the curve, the result of scalar multiplication of **secret key 🔑**($K$) and generator point ($G$). Allows anyone to verify Alice's signature.\n\n```python\nsage: P = K*G\n(858 : 832 : 1)\n```\n\nWe have established that Alice's key pair $=[P, K] = [(858, 832), 42]$.\n\n## ECDSA in action\n\nECDSA is a variant of the Digital Signature Algorithm (DSA). It creates a signature based on a \"fingerprint\" of the message using a cryptographic hash.\n\nFor ECDSA to work, Alice and Bob must establish a common set of domain parameters. Domain parameters for this example are:\n\n| Parameter | Value |\n| ------------------------------------- | --------------- |\n| The elliptic curve equation. | $y^2 = x^3 + 7$ |\n| The prime modulo of the finite field. | 997 |\n| The generator point, $G$. | (174, 487) |\n| The order of the subgroup, $n$. | 1057 |\n\nImportantly, Bob is confident that the public key $P = (858, 832)$ actually belongs to Alice.\n\n### Signing\n\nAlice intends to sign the message **\"Send $1 million\"**, by following the steps:\n\n1. Compute the cryptographic hash **$m$**.\n\n```python\nsage: m = hash(\"Send $1 million\")\n-7930066429007744594\n```\n\n2. For every signature, a random **ephemeral key pair [$eK$, $eP$]** is generated to mitigate an [attack](https://youtu.be/DUGGJpn2_zY?si=4FZ3ZlQZTG9-eah9&t=2117) exposing her **secret key 🔑**.\n\n```python\n# Randomly selected ephemeral secret key.\nsage: eK = 10\n# Ephemeral public key.\nsage: eP = eK*G\n(215 : 295 : 1)\n```\n\nEphemeral key pair $=[eK, eP] = [10, (215, 295)]$.\n\n3. Compute signature component **$s$**:\n\n$$ s = k^{−1} (e + rK ) \\pmod n$$\n\nWhere $r$ is the x-coordinate of the ephemeral public key **(eP)**, i.e **215**. Notice the signature uses both Alice's **secret key 🔑 ($K$)** and the ephemeral key pair **[$eK$, $eP$]**.\n\n```python\n# x-coordinate of the ephemeral public key.\nsage: r = int(eP[0])\n215\n# Signature component, s.\nsage: s = mod(eK**-1 * (m + r*K), n)\n160\n```\n\nThe tuple $(r,s) = (215, 160)$ is the **signature pair**.\n\nAlice then writes the message and signature to the postcard.\n\n\n\n### Verification\n\nBob verifies the signature by independently calculating the **exact same ephemeral public key** from the signature pair **$(r,s)$**, message, and Alice's public key **$P$**:\n\n1. Compute the cryptographic hash **$m$**.\n\n```python\nsage: m = hash(\"Send $1 million\")\n-7930066429007744594\n```\n\n2. Compute the ephemeral public key **$R$**, and compare it with **$r$**:\n\n$$R = (es^{−1} \\pmod n)*G + (rs^{−1} \\pmod n)*P$$\n\n```python\nsage: R = int(mod(m*s^-1,n)) * G + int(mod(r*s^-1,n)) * P\n(215 : 295 : 1)\n# Compare the x-coordinate of the ephemeral public key.\nsage: R[0] == r\nTrue # Signature is valid ✅\n```\n\nIf Alice's captors were to modify the message, it would alter the cryptographic hash, leading to verification failure due to the mismatch with the original signature.\n\n```python\nsage: m = hash(\"Send $5 million\")\n7183426991750327432 # Hash is different!\nsage: R = int(mod(m*s^-1,n)) * G + int(mod(r*s^-1,n)) * P\n(892 : 284 : 1)\n# Compare the x-coordinate of the ephemeral public key.\nsage: R[0] == r\nFalse # Signature is invalid ❌\n```\n\nVerification of the signature assures Bob of the message's authenticity, enabling him to transfer the funds and rescue Alice. Elliptic curves saves the day!\n\n## Wrapping up\n\nJust like Alice, every account on the [Ethereum uses ECDSA to sign transactions](https://web.archive.org/web/20240229045603/https://lsongnotes.wordpress.com/2018/01/14/signing-an-ethereum-transaction-the-hard-way/). However, ECC in Ethereum involves additional security considerations. While the core principles remain the same, we use secure hash functions like keccak256 and much larger prime field, boasting 78 digits: $2^{256}-2^{32}-977$.\n\n\n\nThis discussion is a preliminary treatment of Elliptic Curve Cryptography. For a nuanced understanding, consider the resources below.\n\nAnd finally: **never roll your own crypto!** Use trusted libraries and protocols to protect your data and transactions.\n\n> ℹ️ Note \n> ECDSA faces potential obsolescence from quantum computers – learn about how [Post-Quantum Cryptography tackles this challenge.](/wiki/Cryptography/post-quantum-cryptography.md)\n\n## Further reading\n\n**Elliptic curve cryptography**\n\n- 📝 Standards for Efficient Cryptography Group (SECG), [\"SEC 1: Elliptic Curve Cryptography.\"](http://www.secg.org/sec1-v2.pdf)\n- 📝 Standards for Efficient Cryptography Group (SECG), [\"SEC 2: Recommended Elliptic Curve Domain Parameters.\"](http://www.secg.org/sec2-v2.pdf)\n- 📘 Alfred J. Menezes, Paul C. van Oorschot and Scott A. Vanstone, [Handbook of Applied Cryptography](https://cacr.uwaterloo.ca/hac/)\n- 🎥 Fullstack Academy, [\"Understanding ECC through the Diffie-Hellman Key Exchange.\"](https://www.youtube.com/watch?v=gAtBM06xwaw)\n- 📝 Andrea Corbellini, [\"Elliptic Curve Cryptography: a gentle introduction.\"](https://andrea.corbellini.name/2015/05/17/elliptic-curve-cryptography-a-gentle-introduction/)\n- 📝 William A. Stein, [\"Elliptic Curves.\"](https://wstein.org/simuw06/ch6.pdf)\n- 📝 Khan Academy, [\"Modular Arithmetic.\"](https://www.khanacademy.org/computing/computer-science/cryptography/modarithmetic/a/what-is-modular-arithmetic)\n- 🎥 Khan Academy, [\"The discrete logarithm problem.\"](https://www.youtube.com/watch?v=SL7J8hPKEWY)\n\n**Mathematics of Elliptic Curves**\n\n- 📘 Joseph H. Silverman, [\"The Arithmetic of Elliptic Curves.\"](https://books.google.co.in/books?id=6y_SmPc9fh4C&redir_esc=y)\n- 📝 Joseph H. Silverman, [\"An Introduction to the Theory of Elliptic Curves.\"](https://www.math.brown.edu/johsilve/Presentations/WyomingEllipticCurve.pdf)\n- 📘 Neal Koblitz, [\"A Course in Number Theory and Cryptography.\"](https://link.springer.com/book/10.1007/978-1-4419-8592-7)\n- 📝 Ben Lynn, [\"Stanford Crypto: Elliptic Curves.\"](https://crypto.stanford.edu/pbc/notes/elliptic/)\n- 📝 Rareskills.io, [\"Elliptic Curve Point Addition.\"](https://www.rareskills.io/post/elliptic-curve-addition)\n- 📝 John D. Cook, [\"Finite fields.\"](https://www.johndcook.com/blog/finite-fields/)\n\n**Useful tools**\n\n- 🎥 Tommy Occhipinti, [\"Elliptic curves in Sage.\"](https://www.youtube.com/watch?v=-fRWR_QKzuI)\n- 🎥 Desmos, [\"Introduction to the Desmos Graphing Calculator.\"](https://www.youtube.com/watch?v=RKbZ3RoA-x4)\n- 🧮 Andrea Corbellini, [\"Interactive Elliptic Curve addition and multiplication.\"](https://andrea.corbellini.name/ecc/interactive/reals-add.html)\n\n## Credits\n\n- Thanks to Michael Driscoll for his work on [animated elliptic curves.](https://github.com/syncsynchalt/animated-curves)\n" }, { "path": "docs/wiki/Cryptography/intro.md", "content": "# Cryptography\n\n> :warning: This article is a [stub](https://en.wikipedia.org/wiki/Wikipedia:Stub), help the wiki by [contributing](/contributing.md) and expanding it.\n\nCryptography researchers craft the weapons or implements of change that developers use. They use advanced algebra to exploit the hard limits set by the universe on reality and craft cryptographic schemas that obey certain properties. They are in a sense reality-hackers. They hack reality to create systems that obey objective properties due to the underlying mathematics. \n\n## Cryptography in Ethereum: Core Primitives and Protocol Roles\n\nEthereum’s security model depends on carefully chosen cryptographic constructions, each addressing specific constraints—whether in transaction validation, consensus, or scalability. Below is a breakdown of the key schemes and their protocol-level functions at a high-level. Some of the schemes are discussed in a more detailed level in the Cryptography subsections.\n\n1. ### ECDSA and Transaction Authentication**\n**Usage:** Every Ethereum transaction must be signed using ECDSA over the secp256k1 curve.\n\n#### Why It Matters:\n\nUnlike account abstraction models (ERC-4337), EOAs require signatures for every operation.\n\nThe v, r, s signature format has historical quirks—legacy transactions use v ∈ {27, 28}, while [EIP-155](https://eips.ethereum.org/EIPS/eip-155) defines v ∈ {0, 1} to prevent replay attacks.\n\n**Caveats:**\n\nSignature malleability was a concern pre-EIP-155 (fixed via chainID inclusion).\n\nHardware wallets often implement custom signing logic (e.g., Ledger’s nonce derivation).\n\n2. ### Keccak-256: Beyond \"Just a Hash Function\"\n\n#### Protocol Roles:\n\nBlock hashing (including the mixHash in PoW).\n\nState trie keys (Merkle-Patricia Trees rely on Keccak for node references).\n\n#### Design Choice:\n\nEthereum adopted Keccak before NIST standardized SHA-3, leading to subtle differences (e.g., padding rules).\n\nAlternatives like Blake2b were considered but rejected for compatibility reasons.\n\n3. ### BLS Signatures in PoS: Tradeoffs and Optimizations\n#### Why BLS?\n\nSignature aggregation allows thousands of validator attestations to compress into a single 96-byte proof.\n\nThe BLS12-381 curve balances performance and security (pairing-friendly but slower than secp256k1).\n\nImplementation Nuances:\n\nEthereum’s BLS spec (EIP-2335) enforces strict subgroup checks to avoid rogue-key attacks.\n\nTools like blst and herumi optimize for different environments (e.g., x86 vs. ARM).\n\n4. ### Verkle Trees: A Shift in State Proofs\n**Current Limitation:** Merkle proofs for storage are too large (~1 KB per proof).\n\n**Verkle Solution:**\n\nReplaces hashes with polynomial commitments (KZG), reducing witness sizes to ~200 bytes.\n\nRequires a trusted setup (Ethereum’s KZG ceremony).\n\n**Open Questions:**\n\nHow to handle historical proofs post-transition?\n\nWill gas costs for proof verification change?\n\n5. ### ZKPs in Practice: More Than Just Rollups\n**zkEVM Challenges:**\n\nProving EVM execution requires handling variable opcode costs (e.g., SSTORE vs. ADD).\n\nSome circuits (e.g., Keccak) are notoriously hard to optimize.\n\n**Beyond Rollups:**\n\nLight clients could use ZK proofs for sync committee verification (PBS proposals).\n\nPrivacy pools (e.g., ZK-based anonymous transactions) are under research.\n\n6. ### Post-Quantum Readiness: Not Just Theoretical\n**Immediate Risks:**\n\nQuantum computers could forge ECDSA signatures, but breaking hash functions (Keccak) is harder.\n\n**Migration Paths:**\n\nLattice-based schemes (e.g., Dilithium) are leading candidates, but key sizes are problematic (~2 KB per key).\n\nHybrid approaches (e.g., BLS + SPHINCS+) might bridge the transition.\n\n\n- [BLS12-381 Keystore](https://eips.ethereum.org/EIPS/eip-2335)\n- [Vitalik's ZK-SNARK Explainer](https://vitalik.eth.limo/general/2021/01/26/snarks.html)\n- [Secp256k1 in Ethereum](https://ethereum.org/en/developers/docs/evm/)\n- [Verkle Trees](https://verkle.info/)\n- [The different types of ZK-EVMs](https://vitalik.eth.limo/general/2022/08/04/zkevm.html)\n- [ZK-SNARKS](https://eprint.iacr.org/2018/046)\n\nhttps://summerofprotocols.com/wp-content/uploads/2023/12/53-BEIKO-001-2023-12-13.pdf" }, { "path": "docs/wiki/Cryptography/keccak256.md", "content": "# Keccak256\n\nKeccak256 is a cryptographic hash function prominently used in the Ethereum blockchain. \n\n## Brief History\n\nKeccak256 originated as a submission to the [NIST cryptographic hash algorithm competition](https://keccak.team/files/Keccak-submission-3.pdf). This competition aimed to identify a new secure hash algorithm to replace SHA-1. The KECCAK algorithm was designed by a team comprising Guido Bertoni, Joan Daemen, Michaël Peeters, and Gilles Van Assche. \n\n## Keccak design\n\nKeccak stands out for its sponge construction, a unique feature that allows it to, \"absorb,\" input data of any length and subsequently, \"squeeze,\" out a hash of the desired length.\n\nThe sponge function, central to Keccak's design, operates in two distinct phases: absorption and squeezing. \n\n### Absorption Phase\n\n- **Input Processing**: During this phase, the input data is divided into blocks and XORed with the sponge's state, known as the bitrate.\n- **Bitrate (`r`)**: The bitrate is a parameter defining the number of bits in the state that interact directly with the input. It determines the efficiency and throughput of the data absorption process.\n- **State Permutation**: After each XOR operation, a permutation function is applied to the entire state, ensuring thorough mixing of the input and state.\n\n### Squeezing Phase\n\n- **Output Generation**: Once the absorption is complete, the squeezing phase begins. Here, the output hash is generated from the bitrate portion of the state.\n- **Arbitrary Output Length**: The squeezing phase can produce an output of any desired length.\n\nFor a deeper understanding of Keccak's internal workings, the [Keccak reference](https://keccak.team/files/CSF-0.1.pdf) provides detailed insights into its algorithms and security features.\n\n## EVM Implementation\n\nThe EVM (Ethereum Virtual Machine) processes the execution of transactions for the Ethereum blockchain with a stack based architecture. EVM opcodes are predefined instructions that the EVM interprets and subsequently executes to fulfill transaction and run the smart contracts. There are arithmetic, environmental, control flow, and stack operations Opcodes. Now there is no keccak256 opcode, but there is a SHA3 opcode. The SHA3 opcode is used to encrypt input data from the stack and outputs a Keccak256 hash.\n\nThe [Ethereum Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf), outlines other implementations of Keccak256 in the Ethereum blockchain:\n\n### Usage in Block Creation and Root Data Structure\n\n- **Block Header Fields**: Various fields in the block header, such as `parentHash` and `stateRoot`, use the Keccak 256-bit hash. This includes hashing the entire header of the parent block, the root node of the state trie, and the root nodes of the trie structures for transactions and receipts.\n- **Merkle Patricia Tree**: Ethereum employs a Merkle Patricia Tree to encode its state, where each node in the tree is identified through the Keccak 256-bit hash of its content. This structure underpins the stateRoot field in the block header.\n- **Storage Contents Encoding**: The hash is used to encode the storage contents of accounts, mapping the Keccak 256-bit hash of integer keys to the RLP-encoded integer values.\n\nIn all these instances, Keccak256's role is critical for ensuring data integrity, facilitating efficient data retrieval, and supporting the blockchain's underlying security mechanisms.\n\n## Keccak256 vs SHA3-256\n\n[Quoting Nick Johnson from Ethereum](https://github.com/ethereum/go-ethereum/pull/2940#issuecomment-274809794):\n> SHA3-256 is Keccak256, with the exception of a change in how data is padded. Keccak256 is used because Ethereum's protocol was defined after it was apparent that Keccak256 was the winner of the SHA3 competition, but before the padding change was made.\n\n## References\n\n- [NIST SHA-3 Competition](https://keccak.team/files/Keccak-submission-3.pdf)\n- [Ethereum Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf)\n- [EVM Opcodes](https://www.evm.codes/?fork=shanghai)\n" }, { "path": "docs/wiki/Cryptography/post-quantum-cryptography.md", "content": "# Post-Quantum Cryptography\n\nClassical cryptography safeguards information by leveraging the inherent difficulty of certain mathematical problems. Such group of problems as prime factoring, discrete logarithm, graph isomorphism, and the shortest vector problem etc. fall under the area of mathematical research called the [\"Hidden Subgroup Problem (HSP)\"](https://en.wikipedia.org/wiki/Hidden_subgroup_problem).\n\nIn essence, these problems makes determining the structure of a secret subgroup (size, elements) within a large group computationally intractable without the knowledge of a \"secret\" (private) key. This one-way \"trapdoor function\" is employed by public-key cryptography algorithms for their security.\n\n[RSA's]() security rests on the **factoring of large prime numbers**. In contrast, [ECDSA's](/wiki/Cryptography/ecdsa.md) security is based on the elliptic curve **discrete logarithm problem**. Solving either of these hidden subgroup problems becomes exponentially harder as the key size increases, making them computationally infeasible for classical computers to crack. This fundamental difficulty safeguards encrypted data.\n\nHowever, the landscape is shifting.\n\nQuantum computers, harnessing the principles of quantum mechanics, offer novel computational approaches. Certain quantum algorithms can solve these classical cryptographic problems with exponential efficiency compared to their classical counterparts. This newfound capability poses a significant threat to the security of data encrypted with classical cryptography. If large-scale quantum computers are ever built, they will be able to break many of the public-key cryptography currently in use.\n\n[Shor's algorithm](https://ieeexplore.ieee.org/document/365700) for integer factorization is the most celebrated application of quantum computing. It factors n-digit integers in a time complexity less than $O(n^3)$, a significant improvement over the best classical algorithms.\n\nThis is where the field of post-quantum cryptography comes in. It aims to develop new algorithms that remain secure even in the presence of powerful quantum computers.\n\n## Timeline\n\nAccording to the survey done for [\"Quantum Threat Timeline Report 2020\"](https://globalriskinstitute.org/publication/quantum-threat-timeline-report-2020/) most experts believe that there is <5% threat to the public-key cryptography until 2030. However, it is predicted that the risk substantially increases to about 50% by 2050.\n\nCurrently, the most [advanced quantum computers](https://en.wikipedia.org/wiki/List_of_quantum_processors) have <2000 physical qubits. Breaking Bitcoin's encryption within an hour (ideal time window) [requires approximately 317 million physical qubits](https://pubs.aip.org/avs/aqs/article/4/1/013801/2835275/The-impact-of-hardware-specifications-on-reaching).\n\nSteady progress is being made in quantum research; one survey respondent notes:\n\n> It is not always the case [..] but I find that my predictions are often more pessimistic than what actually happens. I take this as a sign that the research is accelerating.\n\nNote that these predictions are somewhat subjective and might not reflect real progress which is mostly not open to public. Advanced threat actor might have access to powerful quantum computing sooner than public and use strategies like [retrospective decryption](https://en.wikipedia.org/wiki/Harvest_now%2C_decrypt_later).\n\n### 2025\n\nIn Feb 2025, Microsoft announced [a million qubits on a single chip.](https://news.microsoft.com/source/features/innovation/microsofts-majorana-1-chip-carves-new-path-for-quantum-computing/). [Video explanation with context](https://www.youtube.com/watch?v=jwnez8HdN7E). \n\n## Post-Quantum risk to Ethereum\n\nEthereum accounts are secured by a two-tier cryptosystem. A private key is used to generate a public key through [elliptic curve multiplication](/wiki/Cryptography/ecdsa.md). This public key is hashed using [keccak256](/wiki/Cryptography/keccak256.md) to derive the Ethereum address.\n\nThe immediate post-quantum threat is the ability to reverse elliptic curve multiplication securing ECDSA thus exposing the private key. This makes all externally owned accounts (EOA) vulnerable to a quantum attack. Assuming the hashing function that maps a public-key to an ethereum address is still safe, extracting its private key is still challenging but vulnerable nonetheless.\n\nIn practice, most users’ private keys are themselves the result of a bunch of hash calculations using [BIP-32](https://github.com/bitcoin/bips/blob/b3701faef2bdb98a0d7ace4eedbeefa2da4c89ed/bip-0032.mediawiki), which generates each address through a series of hashes starting from a master seed phrase. This makes revealing the private key even more computationally expensive.\n\nEthResearch has an [ongoing proposal](https://ethresear.ch/t/how-to-hard-fork-to-save-most-users-funds-in-a-quantum-emergency/18901) for a hard-fork in the event of a post-quantum emergency, the key actions being:\n\n1. Revert all blocks after the first block where it’s clear that large-scale theft is happening\n2. Traditional EOA-based transactions are disabled\n3. A new transaction type is added to allow transactions from smart contract wallets (eg. part of [RIP-7560](https://ethereum-magicians.org/t/rip-7560-native-account-abstraction/16664)), if this is not available already\n4. A new transaction type or opcode is added by which you can provide a STARK proof which proves knowledge of (i) a private preimage x, (ii) a hash function ID `1 <= i < k` from a list of k approved hash functions, and (iii) a public address A, such that `keccak(priv_to_pub(hashes[i](x)))[12:] = A`. The STARK also accepts as a public input the hash of a new piece of validation code for that account. If the proof passes, your account’s code is switched over to the new validation code, and you will be able to use it as a smart contract wallet from that point forward.\n\nThe approach, however, is not perfect. Some users will still loose funds since not all blocks from the event of an attack will be reverted. This is because it is incredibly hard to reliably detect a quantum attack on the network as [domothy highlights](https://ethresear.ch/t/how-to-hard-fork-to-save-most-users-funds-in-a-quantum-emergency/18901/14):\n\n> Picture a single large exchange wallet being drained by a quantum computer. Everyone would naturally assume it was a security failure of some kind on the exchange’s end. Or if a smart wallet relying on discrete log assumption gets drained, a smart contract bug/exploit would be the first thing that comes to mind. Or the quantum-enabled attacker avoids high profile targets altogether and slowly steals funds from various large EOAs, and we never even know a quantum attack took place.\n\nFurther, KZG commitment schemes powering [EIP-4844](/wiki/research/scaling/core-changes/eip-4844.md) would also need to be upgraded to prevent fraudulent commits.\n\n## Research\n\nPost-quantum cryptography is an active area of research. Several organizations are working on prototyping, development, and standardization of new post-quantum algorithms.\n\n## NIST Post-Quantum Cryptography\n\nThe [NIST Post-Quantum Cryptography standardization](https://csrc.nist.gov/projects/post-quantum-cryptography) conducted a multi-year international competition to evaluate and standardize quantum-resistant cryptographic algorithms. In August 2024, NIST published the first set of finalized **PQC standards** as Federal Information Processing Standards (FIPS):\n\n### Published Standards (August 2024)\n\n**Key encapsulation mechanism:**\n\n- **ML-KEM** ([FIPS 203](https://doi.org/10.6028/NIST.FIPS.203)) derived from CRYSTALS-Kyber. A **key-encapsulation mechanism (KEM)**: a set of three algorithms (KeyGen, Encaps, Decaps) that establish a shared secret key over a public channel. Based on the **Module Learning With Errors (MLWE)** problem.\n\n| Parameter Set | Security Strength | Security Category |\n|---|---|---|\n| ML-KEM-512 | 128 bits | 1 |\n| ML-KEM-768 | 192 bits | 3 |\n| ML-KEM-1024 | 256 bits | 5 |\n\n**Digital signature algorithms:**\n\n- **ML-DSA** ([FIPS 204](https://doi.org/10.6028/NIST.FIPS.204)) derived from CRYSTALS-Dilithium. Lattice-based digital signature algorithm.\n\n| Parameter Set | Security Strength | Security Category |\n|---|---|---|\n| ML-DSA-44 | 128 bits | 2 |\n| ML-DSA-65 | 192 bits | 3 |\n| ML-DSA-87 | 256 bits | 5 |\n\n- **SLH-DSA** ([FIPS 205](https://doi.org/10.6028/NIST.FIPS.205)) derived from SPHINCS+. NIST's stateless hash-based digital signature standard.\n\n It is constructed from three well-studied components:\n - **WOTS+** (Winternitz One Time Signature Plus), one time signing primitive\n - **XMSS** (eXtended Merkle Signature Scheme), multi-time scheme built on WOTS+\n - **FORS** (Forest of Random Subsets), few time scheme for signing message digests\n\n Unlike ML-DSA, SLH-DSA requires **no number-theoretic hardness assumptions**. Security depends only on standard hash-function properties (preimage resistance and related properties), making it resistant to quantum attacks without any algebraic structure that Shor’s algorithm could exploit.\n\n Each security level offers two variants:\n - `s` = smaller signatures, slower signing\n - `f` = larger signatures, faster signing\n\n| Parameter Set | Security Category | Signature Size |\n|----------------------------------------|-------------------|----------------|\n| SLH-DSA-SHA2-128s / SLH-DSA-SHAKE-128s | 1 | 7,856 bytes |\n| SLH-DSA-SHA2-128f / SLH-DSA-SHAKE-128f | 1 | 17,088 bytes |\n| SLH-DSA-SHA2-192s / SLH-DSA-SHAKE-192s | 3 | 16,224 bytes |\n| SLH-DSA-SHA2-192f / SLH-DSA-SHAKE-192f | 3 | 35,664 bytes |\n| SLH-DSA-SHA2-256s / SLH-DSA-SHAKE-256s | 5 | 29,792 bytes |\n| SLH-DSA-SHA2-256f / SLH-DSA-SHAKE-256f | 5 | 49,856 bytes |\n\nThe SHA2 and SHAKE variants differ only in the internal hash-function instantiation (SHA-2 family vs SHAKE from FIPS 202), not in security level or signature structure.\n\n- **FN-DSA** (forthcoming as [FIPS 206](https://csrc.nist.gov/presentations/2025/fips-206-fn-dsa-falcon)) derived from FALCON. Full name: **Fast-Fourier Transform over NTRU-Lattice-Based Digital Signature Algorithm**. A lattice-based scheme in the Hash-Then-Sign paradigm, signing produces a lattice point close to a target derived from a randomized message hash, using **FFT** and an **LDL tree** for discrete Gaussian sampling. This gives FN-DSA significantly smaller signatures and public keys than ML-DSA, making it suited for bandwidth-constrained environments such as certificate chains or protocols with strict size limits.\n \nNIST's [\"Status Report on the Fourth Round of the NIST Post-Quantum Cryptography Standardization Process\"](https://nvlpubs.nist.gov/nistpubs/ir/2025/NIST.IR.8545.pdf) (March 2025) summarizes the ongoing fourth round.\n\n\n### Post-Quantum Cryptography Alliance\n\n[Post-Quantum Cryptography Alliance (PQCA)](https://pqca.org/), an open and collaborative initiative by [linux foundation](https://www.linuxfoundation.org/press/announcing-the-post-quantum-cryptography-alliance-pqca) to drive the advancement and adoption of post-quantum cryptography.\n\n[The Open Quantum Safe (OQS)](https://openquantumsafe.org/) project under this initiative is an open-source project that aims to support the transition to quantum-resistant cryptography.\n\n### The Crypto Forum Research Group\n\nThe [Crypto Forum Research Group](https://datatracker.ietf.org/rg/cfrg/about/) within the Internet Engineering Task Force has standardized the stateful hash-based signature scheme [\"XMSS: eXtended Merkle Signature Scheme.\"](https://datatracker.ietf.org/doc/rfc8391/)\n\n## Production usage\n\nFollowing pilot projects and research initiatives are exploring PQC usage in production:\n\n- [Anchor Vault](https://chromewebstore.google.com/detail/omifklijimcjhfiojhodcnfihkljeali) is a chrome plugin allows adding a quantum-resistant proof using Lamport's signature for securing ERC tokens.\n- Signal has implemented [\"Post-Quantum Extended Diffie-Hellman\"](https://signal.org/docs/specifications/pqxdh/#introduction) in production for key agreement protocol.\n- Chromium started supporting [\"Hybrid Kyber KEM\"](https://blog.chromium.org/2023/08/protecting-chrome-traffic-with-hybrid.html) to protect data in transit.\n- Apple has implemented [PQ3](https://security.apple.com/blog/imessage-pq3/) to protect iMessage against key compromise from a quantum attack.\n\n## Resources\n\n- 📝 Daniel J. Bernstein and et al, [\"Introduction to post-quantum cryptography\"](https://pqcrypto.org/www.springer.com/cda/content/document/cda_downloaddocument/9783540887010-c1.pdf)\n- 📝 Wikipedia, [\"Quantum algorithm.\"](https://en.wikipedia.org/wiki/Quantum_algorithm)\n- 📝 P.W. Shor, [\"Algorithms for quantum computation: discrete logarithms and factoring.\"](https://ieeexplore.ieee.org/document/365700)\n- 📝 NIST, [\"Post-Quantum Cryptography.\"](https://csrc.nist.gov/projects/post-quantum-cryptography)\n- 📝 ETHResearch, [\"How to hard-fork to save most users’ funds in a quantum emergency.\"](https://ethresear.ch/t/how-to-hard-fork-to-save-most-users-funds-in-a-quantum-emergency/18901)\n- 📝 ETHResearch, [\"ETHResearch: Post-Quantum\"](https://ethresear.ch/tag/post-quantum)\n- 📝 Vitalik Buterin, [\"STARKs, Part I: Proofs with Polynomials.\"](https://vitalik.eth.limo/general/2017/11/09/starks_part_1.html)\n- 📝 Wikipedia, [\"Lamport's Signature.\"](https://en.wikipedia.org/wiki/Lamport_signature)\n" }, { "path": "docs/wiki/EL/JSON-RPC.md", "content": "# JSON-RPC\n\nThe JSON-RPC specification is a remote procedure call protocol encoded in JSON based on [OpenRPC](https://www.open-rpc.org/docs/getting-started). It allows calling functions on a remote server, and for the return of the results.\nIt is part of the Execution API specification which provides a set of methods to interact with the Ethereum blockchain.\nIt is better known to be the way of how the users interact with the network using a client, even how the consensus layer (CL) and the execution layer (EL) interact through the Engine API.\nThis section provides a description of the JSON-RPC methods.\n\n## API Specification\n\nThe JSON-RPC methods are grouped by namespaces specified as a method prefix. Even though they all have different purposes, all of them share a common structure and must behave the same across all implementations:\n\n```json\n{\n \"id\": 1,\n \"jsonrpc\": \"2.0\",\n \"method\": \"\",\n \"params\": [...]\n}\n```\n\nWhere:\n- `id`: A unique identifier for the request.\n- `jsonrpc`: The version of the JSON-RPC protocol.\n- `method`: The method to be called.\n- `params`: The parameters for the method. It can be an empty array if the method does not require any parameters. Other ones may have default values if not provided.\n\n### Namespaces\n\nEvery method is composed of a namespace prefix and the method name, separated by an underscore.\n\nEthereum clients must implement the basic minimum set of RPC methods required by spec to interact with the network. On top of that, there are also client specific methods for controlling the node or implementing extra unique features. Always refer to client documentation listing available methods and namespace, for example notice different namespaces in [Geth](https://geth.ethereum.org/docs/interacting-with-geth/rpc) and [Reth](https://reth.rs/jsonrpc/intro/) docs. \n\nHere are examples of most common namespaces: \n\n| **Namespace** | **Description** | **Sensitive** |\n| ------------- | ---------------------------------------------------------------------------------------------------- | ------------- |\n| eth | The eth API allows you to interact with Ethereum. | Maybe |\n| web3 | The web3 API provides utility functions for the web3 client. | No |\n| net | The net API provides access to network information of the node. | No |\n| txpool | The txpool API allows you to inspect the transaction pool. | No |\n| debug | The debug API provides several methods to inspect the Ethereum state, including Geth-style traces. | No |\n| trace | The trace API provides several methods to inspect the Ethereum state, including Parity-style traces. | No |\n| admin | The admin API allows you to configure your node. | Yes |\n| rpc | The rpc API provides information about the RPC server and its modules | No |\n\nSensitive means they could be used to set up the node, such as *admin*, or access account data stored in the node, just like *eth*.\n\nNow, let's take a look at some methods to understand how they are built and what they do:\n\n#### Eth\n\nEth is probably the most used namespace providing basic access to Ethereum network, e.g. it's necessary for wallets to read balance and create transactions. \nJust a brief list of the methods is provided here, but the full list can be found in the [Ethereum JSON-RPC specification](https://ethereum.github.io/execution-apis/api-documentation/).\n\n| **Method** | **Params** | **Description** |\n| ------------------------------------ |:-------------------------------:| ------------------------------------------------------------------------------------------------------------------------------------------- |\n| eth_blockNumber | no mandatory params | returns the number of the most recent block |\n| eth_call | transaction object | executes a new message call immediately without creating a transaction on the block chain |\n| eth_chainId | no mandatory params | returns the current chain id |\n| eth_estimateGas | transaction object | makes a call or transaction, which won't be added to the blockchain and returns the used gas, which can be used for estimating the used gas |\n| eth_gasPrice | no mandatory params | returns the current price per gas in wei |\n| eth_getBalance | address, block number | returns the balance of the account of the given address |\n| eth_getBlockByHash | block hash, full txs | returns information about a block by hash |\n| eth_getBlockByNumber | block number, full txs | returns information about a block by block number |\n| eth_getBlockTransactionCountByHash | block hash | returns the number of transactions in a block from a block matching the given block hash |\n| eth_getBlockTransactionCountByNumber | block number | returns the number of transactions in a block from a block matching the given block number |\n| eth_getCode | address, block number | returns code at a given address in the blockchain |\n| eth_getLogs | filter object | returns an array of all logs matching a given filter object |\n| eth_getStorageAt | address, position, block number | returns the value from a storage position at a given address |\n\n#### Debug\n\nThe *debug* namespace provides methods to inspect the Ethereum state. It's direct access to raw data which might be necessary for certain use cases like block explorers or research purposes. Some of these methods might require a lot of computation to be done on the node and requests for historical states on non-archival node are mostly not feasible. Therefore, providers of public RPCs often restrict this namespace or allow only safe methods. \nHere are basic examples of debug methods: \n\n| **Method** | **Params** | **Description** |\n|--------------------------|:---------------------:|-----------------------------------------------------------------|\n| debug_getBadBlocks | no mandatory params | returns and array of recent bad blocks that the client has seen |\n| debug_getRawBlock | block_number | returns an RLP-encoded block |\n| debug_getRawHeader | block_number | returns an RLP-encoded header |\n| debug_getRawReceipts | block_number | returns an array of EIP-2718 binary-encoded receipts |\n| debug_getRawTransactions | tx_hash | returns an array of EIP-2718 binary-encoded transactions |\n\n#### Engine\n\n[Engine API](https://hackmd.io/@danielrachi/engine_api) is different from the aforementioned general Ethereum JSON‑RPC methods. Execution clients serve the Engine API on a separate, authenticated endpoint rather than on the normal HTTP JSON‑RPC port because it is not a user-facing API. Its sole purpose is to facilitate inter-client communication exchanging information about consensus, fork choice, and block validation between the consensus and execution clients.\n\nInter-client communication operates over a JSON‑RPC interface over HTTP and is secured using a JSON Web Token (JWT). The JWT authenticates the sender as a valid consensus layer client, although it does not provide traffic encryption. Furthermore, the Engine JSON‑RPC endpoint is only accessible by the consensus layer, ensuring that malicious external parties cannot interact with it.\n\nThe following table lists core Engine API methods and provides a brief description of their purpose and the parameters they accept:\n| **Method** | **Params** | **Description** |\n|------------------------------------------|:--------------------------------------:|---------------------------------------------------------------------------|\n| engine_exchangeTransitionConfigurationV1 | Consensus client config | Exchanges configuration details between CL and EL |\n| engine_forkchoiceUpdatedV1* | forkchoice_state, payload attributes | Updates the forkchoice state and optionally initiates payload building |\n| engine_getPayloadBodiesByHashV1* | block_hash (array) | Given block hashes, returns the corresponding execution payload bodies |\n| engine_getPayloadV1* | forkchoice_state, payload attributes | Obtains an execution payload that has been built by the EL |\n| debug_newPayloadV1* | tx_hash | Returns execution payload validation details for debugging purposes |\n\nThose methods marked with an asterisk (*) have more than one version to support network upgrades and evolving protocol features. The [Ethereum JSON-RPC specification](https://ethereum.github.io/execution-apis/api-documentation/) provides detailed documentation on these methods.\n\n## Encoding\n\nThere is a convention for encoding the parameters of the JSON-RPC methods, which is the hex encoding.\n* Quantities are represented as hexadecimal values using a \"0x\" prefix.\n * For example, the number 65 is represented as \"0x41\".\n * The number 0 is represented as \"0x0\".\n * Some invalid usages are \"0x\" and \"ff\". Since the first case does not have a following digit and the second one is not prefixed with \"0x\". \n* Unformatted data, such as hashes, account addresses or byte arrays, are hex encoded using a \"0x\" prefix as well.\n * For example: 0x400 (1014 in decimal)\n * An invalid case is 0x0400 because leading zeroes are not allowed\n\n## Transport agnostic\n\nWorth to mention here the JSON-RPC is transport agnostic, meaning it can be used over any transport protocol, such as HTTP, WebSockets (WSS), or even Inter-Process Communication (IPC).\nTheir differences can be summarized as it follows:\n* **HTTP** transport provides an unidirectional response-request model, which gets the connection closed after the response is sent.\n* **WSS** is a bidirectional protocol, which means the connection is kept open until either the node or the user explicitly closes it. It allows subscriptions-based model communication such as event-driven interactions.\n* **IPC** transport protocol is used for communication between processes running on the same machine. It is faster than HTTP and WSS, but it is not suitable for remote communication, e.g. it can be used via local JS console.\n \n## Tooling\n\nThere are several ways of how to use the JSON-RPC methods. One of them is using the `curl` command. For example, to get the latest block number, you can use the following command:\n\n```bash\ncurl \\\n-X POST \\\n-H \"Content-Type: application/json\" \\\n-d '{\"jsonrpc\":\"2.0\",\"method\":\"eth_blockNumber\",\"params\":[],\"id\":1}'\n```\nPlease note how the *params* field is empty, as the method passes \"latest\" as its default value.\n\nAnother way is to use the `axios` library in Javascript/TypeScript. For example, to get the address balance, you can use the following code:\n\n```typescript\nimport axios from 'axios';\n\nconst node = '';\nconst address = '
';\n\nconst response = await axios.post(node, {\n jsonrpc: '2.0',\n method: 'eth_getBalance',\n params: [address, 'latest'],\n id: 1,\n headers: {\n 'Content-Type': 'application/json',\n },\n});\n```\nAs you may notice, the JSON-RPC methods are wrapped in a POST request, and the parameters are passed in the body of the request.\nThis is a different way to exchange data between the client and the server using the OSI's application layer: the HTTP protocol.\n\nEither way, the most common use to interact with the Ethereum network is using web3 libraries, such as web3py for python or web3.js/ethers.js for JS/TS:\n\n#### web3py\n\n```python\nfrom web3 import Web3\n\n# Set up HTTPProvider\nw3 = Web3(Web3.HTTPProvider('http://localhost:8545'))\n\n# API\nw3.eth.get_balance('0xaddress')\n```\n\n#### ethers.js\n\n```typescript\nimport { ethers } from \"ethers\";\n\nconst provider = new ethers.providers.JsonRpcProvider('http://localhost:8545');\n\nawait provider.getBlockNumber();\n```\n\nUsually, all the web3 libraries wrap the JSON-RPC methods providing a more friendly way to interact with the execution layer. Please, look forward in your preferred programming language as the syntax may vary.\n\n### Further Reading\n* [Ethereum JSON-RPC Specification](https://ethereum.github.io/execution-apis/api-documentation/)\n* [Execution API Specification](https://github.com/ethereum/execution-apis/tree/main)\n* [JSON-RPC | Infura docs](https://docs.metamask.io/services/reference/ethereum/json-rpc-methods/)\n* [reth book | JSON-RPC](https://reth.rs/jsonrpc/intro/)\n* [OpenRPC](https://www.open-rpc.org/docs/getting-started)\n* [Engine API | Mikhail | Lecture 21](https://youtu.be/fR7LBXAMH7g)\n" }, { "path": "docs/wiki/EL/RLP.md", "content": "# Recursive-Length Prefix (RLP) Serialization\n\nRecursive Length Prefix (RLP) is a core serialization protocol used within the execution layer for encoding and parsing data. It is designed to serialize data and produce a structure readable by all client software. It is used for everything from transaction data to the entire state of the blockchain. This wiki page explores the internals of RLP, its encoding/decoding rules, tools available and its role in Ethereum's functionality.\n\n## Data Serialization in Ethereum\n\nData serialization is the process of converting data structures or objects into a byte stream for storage, transmission, or later reconstruction. In distributed systems like Ethereum, serialization is crucial for transmitting data across network nodes reliably and efficiently. Clients written in different languages need to be able to process data the same way. Data communicated to other nodes or exported by the client need to have a standard format. While there are common serialization formats like JSON, XML or Protobuf, Ethereum uses its own protocols for its simplicity and effectiveness in encoding nested arrays of bytes.\n\n> Ethereum actually utilizes 2 formats: RLP and Simple Serialize (SSZ) which is more modern standard used by consensus layer.\n\n## How RLP Algorithm works\n\n**RLP encoding algorithm**\n\nHere is a flow chart describing how RLP encoding algorithm works.\n\n_Note that in some RLP tools, some clients may add additional conditional cases to the flow. These additional cases are not part of the standard specification but they are useful for the clients for the correct data serialization, e.g. geth client node communicating with a Nethermind client node._\n\n```mermaid\nflowchart TD\n A[Start: Input] --> B{Is Input null, empty string, or false?}\n B -->|Yes| C[Encode as Single Byte 0x80]\n B -->|No| D{Is it a Single Byte and < 0x80?}\n D -->|Yes| E[Directly Encode the Byte]\n D -->|No| F{Is it a String or List?}\n F -->|String| G{String Length <= 55}\n G -->|Yes| H[Encode with Length + 0x80]\n G -->|No| I[Encode Length with 0xB7 + Length Bytes]\n F -->|List| J{Total Encoded Items Length <= 55}\n J -->|Yes| K[Encode with Total Length + 0xC0]\n J -->|No| L[Encode Total Length with 0xF7 + Length Bytes]\n H --> M[Output Encoded Data]\n I --> M\n K --> M\n L --> M\n E --> M\n C --> M\n```\n\n_Figure: RLP Encoding Flow_\n\n**RLP decoding algorithm**\n\nHere is a flow chart describing how RLP decoding algorithm works.\n\n```mermaid\nflowchart TD\n A[Start: Encoded Input] --> B{Check First Byte}\n B -->|0x00 to 0x7F| C[Direct Byte Output]\n B -->|0x80| D[Decode as Empty String/Null/False]\n B -->|0x81 to 0xB7| E[Short String]\n E --> F[Subtract 0x80 from First Byte to get Length]\n F --> G[Output Next 'Length' Bytes as String]\n B -->|0xB8 to 0xBF| H[Long String]\n H --> I[Subtract 0xB7 from First Byte to get Length Bytes Count]\n I --> J[Read Next 'Length Bytes Count' to Determine String Length]\n J --> K[Output Next 'String Length' Bytes as String]\n B -->|0xC0 to 0xF7| L[Short List]\n L --> M[Subtract 0xC0 from First Byte to get Total Encoded Length]\n M --> N[Decode Each Element in the Next 'Total Encoded Length' Bytes Recursively]\n B -->|0xF8 to 0xFF| O[Long List]\n O --> P[Subtract 0xF7 from First Byte to get Length Bytes Count]\n P --> Q[Read Next 'Length Bytes Count' to Determine List Total Length]\n Q --> R[Decode Each Element in the Next 'List Total Length' Bytes Recursively]\n C --> S[Output Decoded Data]\n D --> S\n G --> S\n K --> S\n N --> S\n R --> S\n```\n\n_Figure: RLP Decoding Flow_\n\n\n## RLP Encoding Rules\n\nUnderstanding how RLP encoding is derived requires a grasp of the specific rules applied based on the type and size of the data. Let's explore these rules using an example to demonstrate how different types of data are encoded.\n\nIf you are not familiar with converting the strings to hex, you may refer to this [ASCII chart](https://www.asciitable.com/). \n\n### Detailed Explanation of RLP Encoding Rules with Example\n\nRecursive Length Prefix (RLP) is a fundamental data serialization technique used in Ethereum to encode structured data into a sequence of bytes. Understanding how RLP encoding is derived requires a grasp of the specific rules applied based on the type and size of the data. Let's explore these rules step-by-step using an example to demonstrate how different types of data are encoded.\n\n**Single Byte Encoding**\n - **Condition**: If the input is a single byte and its value is between `0x00` and `0x7F` (inclusive).\n - **Encoding**: The byte is encoded directly, unchanged.\n - **Example**: Encoding the byte `0x2a` directly yields `0x2a`.\n\n**Short String Encoding (1-55 bytes)**\n - **Condition**: If the string (or byte array) length is between 1 and 55 bytes.\n - **Encoding**: The output is the length of the string plus `0x80`, followed by the string itself.\n - **Example**: Encoding the string \"dog\" (`0x64, 0x6f, 0x67`) results in `0x83, 0x64, 0x6f, 0x67`. Here, `0x83` is `0x80 + 3` (the length of \"dog\").\n\n**Long String Encoding (over 55 bytes)**\n - **Condition**: If the string length exceeds 55 bytes.\n - **Encoding**: The length of the string is encoded as a byte array in big-endian format, prefixed by `0xb7` plus the length of this length array.\n - **Example**: For a string of length 56, the length `0x38` is encoded, preceded by `0xb8` (`0xb7 + 1`). The resulting encoding starts with `0xb8, 0x38`, followed by the string's bytes.\n\n**Short List Encoding (total payload 1-55 bytes)**\n - **Condition**: If the total encoded payload of the list's items is between 1 and 55 bytes.\n - **Encoding**: The list is prefixed with `0xc0` plus the total length of the encoded items.\n - **Example**: For a list `[\"cat\", \"dog\"]`, each item is first encoded to `0x83, 0x63, 0x61, 0x74` and `0x83, 0x64, 0x6f, 0x67`. The total length is 8, so the prefix is `0xc8` (`0xc0` + 8 = `0xc8`). The entire encoding is `0xc8, 0x83, 0x63, 0x61, 0x74, 0x83, 0x64, 0x6f, 0x67`.\n\n**Long List Encoding (total payload over 55 bytes)**\n - **Condition**: If the total encoded payload of the list's items exceeds 55 bytes.\n - **Encoding**: Similar to long strings, the length of the payload is encoded in big-endian format, prefixed by `0xf7` plus the length of this length array.\n - **Example**: For a list `[\"apple\", \"bread\", ...]` exceeding 55 bytes, suppose the payload length is 57. The length `0x39` is encoded, preceded by `0xf8` (`0xf7 + 1`), followed by the encoded list items.\n\n**Null, Empty String, Empty List and False**\n - Rule for Empty string, Null and False: Encoded as a single byte `0x80`.\n - Rule for Empty List: Encoded as `0xc0`.\n - Examples:\n - Encoding an empty string or a null value or false, (` `, `null`, `false`), result in `0x80`.\n - Encoding an empty list, `[]`, results in `0xc0`.\n\n## RLP Decoding Rules \n\nThe RLP decoding process is based on the structure and specifics of the encoded data:\n\n**Determine Data Type**:\n - The first byte (prefix) of the encoded data determines the type and length of the data that follows. This byte is critical in guiding the decoding process.\n**Decoding Single Bytes**:\n - If the prefix byte is in the range `0x00` to `0x7F`, the byte itself represents the decoded data. This case is straightforward as the byte is encoded directly.\n**Decoding Strings and Lists**:\n - The complexity in decoding arises with strings and lists, which have varying lengths and may contain nested structures.\n**Short Strings (0x80 to 0xB7)**:\n - If the prefix byte is between `0x80` and `0xB7`, it indicates a string whose length can be directly determined by subtracting `0x80` from the prefix. The following bytes equal the length are the string.\n**Long Strings (0xB8 to 0xBF)**:\n - For longer strings, if the prefix byte is between `0xB8` and `0xBF`, the number of length bytes is determined by subtracting `0xB7` from the prefix. The subsequent bytes represent the length of the string, and the bytes following represent the string itself.\n**Short Lists (0xC0 to 0xF7)**:\n - Similar to short strings, a prefix between `0xC0` and `0xF7` indicates a list. The length of the list's encoded data can be determined by subtracting `0xC0` from the prefix. The bytes that follow must then be decoded recursively as individual RLP encoded items.\n**Long Lists (0xF8 to 0xFF)**:\n - For longer lists, a prefix between `0xF8` and `0xFF` indicates that the next few bytes (determined by subtracting `0xF7` from the prefix) will tell the length of the list's encoded data. The data following these length bytes is then recursively decoded into RLP items.\n\n**Examples of RLP Decoding of `[0xc8, 0x83, 0x63, 0x61, 0x74, 0x83, 0x64, 0x6f, 0x67]`**\n\n- **Identify the Prefix**\n - The sequence starts with the byte `0xc8`. In RLP, a list's length prefix starts at `0xc0`. The difference between `0xc8` and `0xc0` gives us the length of the list content.\n - `0xc8 - 0xc0 = 8`\n - This tells us that the next 8 bytes are part of the list.\n- **Decode the List Content**\n - The list content in this example is `[0x83, 0x63, 0x61, 0x74, 0x83, 0x64, 0x6f, 0x67]`.\n - We will decode this content byte by byte to extract the individual items.\n- **Decode the First Item**\n - The first byte of the list content is `0x83`. In RLP, for strings where the length is between 1 and 55 bytes, the length prefix starts at `0x80`. Thus:\n - `0x83 - 0x80 = 3`\n - This tells us that the first string has a length of `3` bytes.\n - The next three bytes are `0x63, 0x61, 0x74`, which correspond to the ASCII values for \"cat\".\n - We have now decoded the first item: \"cat\".\n- **Decode the Second Item**\n - After decoding the first item, the next byte in the sequence is another `0x83`.\n - Following the same rule as before:\n - `0x83 - 0x80 = 3`\n - This indicates the next string also has a length of 3 bytes.\n - The following three bytes are `0x64, 0x6f, 0x67`, corresponding to \"dog\".\n - We have now decoded the second item: \"dog\".\n- The decoded output is `[\"cat\", \"dog\"]`.\n\n## The Need for RLP in Ethereum\n\n> RLP is intended to be a highly minimalistic serialization format; its sole purpose is to store nested arrays of bytes. Unlike protobuf, BSON and other existing solutions, RLP does not attempt to define any specific data types such as booleans, floats, doubles or even integers; instead, it simply exists to store structure, in the form of nested arrays, and leaves it up to the protocol to determine the meaning of the arrays.\n> -- Ethereum's design rationale\n\nRLP was created with Ethereum and is tailored to meet its specific needs:\n- Minimalistic Design: It focuses purely on storing structure without imposing data type definitions.\n- Consistency: It guarantees byte-perfect consistency across different implementations, crucial for the deterministic nature required in blockchain operations.\n\n## RLP Tools\n\nThere are many libraries available for RLP implementations in Ethereum. Here are few tools:\n- [Geth RLP](https://github.com/ethereum/go-ethereum/tree/master/rlp)\n- [RLP Dump](https://github.com/ethereum/go-ethereum/tree/master/cmd/rlpdump)\n- [RLP for Node.js and the browser.](https://github.com/ethereumjs/ethereumjs-monorepo/tree/master/packages/rlp)\n- [Python RLP serialization library.](https://github.com/ethereum/pyrlp)\n- [RLP for Rust](https://docs.rs/ethereum-rlp/latest/rlp/)\n- [Nethermind RLP Serialization](https://github.com/NethermindEth/nethermind/tree/master/src/Nethermind/Nethermind.Serialization.Rlp)\n\n## Resources\n- [Ethereum Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf)\n- [Ethereum RLP documentation](https://ethereum.org/vi/developers/docs/data-structures-and-encoding/rlp/)\n- [A Comprehensive Guide to RLP Encoding in Ethereum by Mark Odayan](https://medium.com/@markodayansa/a-comprehensive-guide-to-rlp-encoding-in-ethereum-6bd75c126de0)\n- [Ethereum's RLP serialization in Elixir](https://www.badykov.com/elixir/rlp/)\n- [Ethereum Under The Hood Part 3 (RLP Decoding)](https://medium.com/coinmonks/ethereum-under-the-hood-part-3-rlp-decoding-df236dc13e58)\n- [Ethereum's Recursive Length Prefix in ACL2](https://arxiv.org/abs/2009.13769)\n\n\n\n" }, { "path": "docs/wiki/EL/block-production.md", "content": "# Block building, processing, and applying transaction to state:\n\n## Intro\n\nBlock building is a crucial task for the Ethereum blockchain's functionality, involving various processes determining how a validator acquires a block before proposing it. Ethereum network consists of nodes running interconnected consensus (CL) and execution clients (EL). Both are essential for network participation and producing block at each slot. While the execution client (EL) has numerous important functionalities you can study more about it in the \"el-architecture\", a key focus here is its role in constructing blocks for consumption by CL.\n\nWhen a validator is selected to propose a block during a slot, it looks for the block produced by CL. Importantly, a validator isn't limited to broadcasting a block solely from its own EL. It can also broadcast a block produced by external builders; for details, refer to [PBS](https://ethereum.org/en/roadmap/pbs/). This article specifically explores how a block is produced by EL and the elements contributing to its successful production and transaction execution.\n\n## Payload building routine\n\nA block is created when the consensus layer instructs the execution layer client to do so through the engine API's fork choice updated endpoint, which then initiates the process of constructing the block via the payload building routine.\n\nNote: The fee recipient of the built payload may deviate from the suggested fee recipient of the payload attributes:\n\n\n\nNodes broadcast transactions through a peer-to-peer network using the gossip protocol. These transactions are validated against specific criteria (e.g. , checking nonce correctness, sufficient balance, and proper signatures) and stored in the mempool awaiting inclusion in a block.\n\nEach slot has a designated block proposer, selected through a pseudo-random process by the consensus layer. When a validator is chosen as the block proposer for a slot, its consensus client initiates block construction through the execution engine's fork choice updated method, which provides the necessary context for building the block.\n\nWe can simplify and emulate the process of constructing blocks, though this approach is specific to the Go types used in geth. However, the concepts can generally be applied to different clients.\n\n```go\nfunc build(env environment, pool txpool.Pool, state state.StateDB) (types.Block, state.StateDB, error) { //1\n var (\n gasUsed = 0\n txs []types.Transactions\n ) //2\n\n for ; gasUsed < 30_000_000 || !pool.Empty(); { //3\n transaction := pool.Pop() //4\n res, gas, err := vm.Run(env, transaction, state) //5\n if err != nil { // 6\n // transaction invalid\n continue\n }\n gasUsed += gas // 7\n transactions = append(transactions, transaction)\n }\n return core.Finalize(env, transactions, state) //8\n}\n```\n\n1. We take in the environment, which contains all the necessary information (similar to the header previously), including the time stamp, block number, preceding block, base fee, and all the withdrawals that need to occur in the block. Essentially, the information originating from the consensus layer, which acts as the central decision-making entity, determines the context in which the block should be constructed. Next, we take in the transaction pool, which is a collection of transactions. For simplicity, we assume that these transactions are arranged in ascending order based on their value. This arrangement helps us construct the most profitable block for the execution client, considering the transactions observed in the network. Additionally, we also consider a state DB, representing the state over which all these transactions are executed.\n - We return a block, a state DB that has accumulated all the transactions in the block and possibly an error.\n2. Inside build we track the gas used because there is only a finite amount of gas we can use. And, also store all the transactions that are going to go in the block.\n3. We continue adding the transactions until the pool is empty or the amount of gas consumed is greater than the gas limit, which is fixed at 30 million (about the current gas limit on the mainnet) in this example for the sake of simplicity.\n4. In order to obtain a transaction, we must query the transaction pool, which is presumed to maintain an ordered list of transactions, ensuring that we always receive the next most valuable transaction.\n5. The transaction is executed in the EVM, assuming that run requires an interface that is satisfied by both the block and the environment. We provide the environment, transaction, and state as input. This  will execute the transaction within the context defined by the environment and provide us with an updated state that will include the accumulated transaction.\n6. If the transaction execution is unsuccessful, indicated by the occurrence of an error during the run, we simply proceed without interruption. This indicates that the transaction is invalid and since there is still unused gas left in the block, we do not want to generate an error immediately. This is because no error has occurred within the block yet. However, it is highly likely that the transaction is invalid because it did something bad during execution or because the transaction pool is slightly outdated. In which case we allow ourselves to continue and try to get the next transaction from the pool into this block.\n7. Once we verify there is no error with running the transaction we add the transaction to the transactions list and we add the gas that was returned by run to the gas used. For example if the first transaction was a simple transfer, which costs 21,000 gas our gas used would go from 0 to 21,000 and we would keep doing this process steps 3-7 until the conditions of step 3 are met.\n8. We finalize our transition by taking set of transactions and relevant block information to generate a fully assembled block. The purpose of doing this is to perform certain calculations at the end. Since the header contains the transactions root, receipts root, and withdrawals root, these values must be computed by merkleizing a list and added to the block's header.\n - We return our block, state DB and our error.\n\n## Code walk-through\n\n### Geth\n\nThe following example is using Geth codebase to explain how execution client builds a block.\n\n 1. Firstly when a validator is chosen as a block builder it calls `engine_forkchoiceUpdatedV2` function via Engine API on the EL. Here, EL initiates the block building process. \n - https://github.com/ethereum/go-ethereum/blob/0a2f33946b95989e8ce36e72a88138adceab6a23/eth/catalyst/api.go#L398 \n 2. Most of the core logic of block building, and transaction execution resides in `miner` module of Geth. The `buildPayload` function initially creates an empty block so the node doesn't miss the slot and has something to propose. The function implementation also starts a go routine process whose job is to potentially fill the block which we left empty and then later update it with filled transactions concurrently.\n - https://github.com/ethereum/go-ethereum/blob/0a2f33946b95989e8ce36e72a88138adceab6a23/miner/payload_building.go#L180 - https://github.com/ethereum/go-ethereum/blob/0a2f33946b95989e8ce36e72a88138adceab6a23/miner/payload_building.go#L204\n 3. In the `buildPayload` function, the go routine is waiting on multiple communication operations \"cases\" and in the first case it calls `getSealingBlock` with params which explicitly specify that the block should not be empty. Look at the `fullParams` variable i.e `noTxs:False`.\n 4. In the definition for `getSealingBlock`, the request is being sent on `getWorkCh` channel. This channel is being listened on in order to retrieve data from it and generate work. \n - [https://github.com/ethereum/goethereum/blob/master/miner/worker.go#L1222](https://github.com/ethereum/go-ethereum/blob/0a2f33946b95989e8ce36e72a88138adceab6a23/miner/worker.go#L1222)\n 5. This `getWorkCh` channel is being listened on inside `mainLoop` function in the same file. The data which comes from the `getWorkCh` channel is then sent to `w.generateWork`.\n - https://github.com/ethereum/go-ethereum/blob/master/miner/worker.go#L537\n 6. `generateWork` function is where transactions get filled inside the block.\n - https://github.com/ethereum/go-ethereum/blob/0a2f33946b95989e8ce36e72a88138adceab6a23/miner/worker.go#L1094\n 7. `w.fillTransactions` function retrieves all the pending transactions from the mempool and fills the block. This includes all types of transactions, including blobs.\n - https://github.com/ethereum/go-ethereum/blob/master/miner/worker.go#L1024\n 8. Transactions are filled with ordering based on their fee and then passed to `commitTransactions` function. \nhttps://github.com/ethereum/go-ethereum/blob/master/miner/worker.go#L1072\n 9. `commitTransactions` function checks that for each transaction we have enough gas left and then commits that particular transaction. Also there is a certain number of blobs allowed per block as specified in eip-4844. \n - https://github.com/ethereum/go-ethereum/blob/master/miner/worker.go#L888 \n - https://github.com/ethereum/EIPs/blob/master/EIPS/eip-4844.md\n 10. If you look into the `commitTransaction` function it in return calls `w.applyTransaction` function.\n - https://github.com/ethereum/go-ethereum/blob/master/miner/worker.go#L760C18-L760C36 \n 11. `applyTransaction` function then goes onto call the core package and calls `core.ApplyTransaction` which executes all the transactions against the local EL state. \n - https://github.com/ethereum/go-ethereum/blob/master/miner/worker.go#L794.\n 12. `ApplyTransaction` function runs the transaction against the local EL state and carries out all the state changes. It creates EVM contexts and environments to execute the transactions in the EVM. The contract calls also all happen here. If all goes well the state is transitioned successfully. \n - https://github.com/ethereum/go-ethereum/blob/master/core/state_processor.go#L161\n13. Also transaction can fail. If transaction fails, it's not applied to the state transition. It can fails due to onchain reasons, e.g. running out of gas, failed contract calls, etc.\n14. From this point on after, all transactions are executed one by one. The transactions are then bundled into a block. \n15. CL then requests EL via Engine API to get this transaction filled with a payload `getPayload`. EL returns this payload to the CL which puts this payload to the beacon block and propagates it.\n \n## Resources\n1. [GETH codebase](https://github.com/ethereum/go-ethereum)\n2. [Engine API: A Visual Guide](https://hackmd.io/@danielrachi/engine_api)\n" }, { "path": "docs/wiki/EL/clients/besu.md", "content": "# Besu Execution Client\n\nThis is a brief summary of important information you need to know when starting to contribute to Besu, a Java implementation of the execution client. \n\nCodebase repository: https://github.com/hyperledger/besu/\nDocs: https://besu.hyperledger.org\n\n## Code directory explanation\n\n### Modules\n+ It is a multi-module [gradle](https://gradle.org/) project. You can take a look to settings.gradle to see all modules:\n + Each module has its own build.gradle:\n\t\t+ You can specify its module name: `archiveBaseName`\n\t\t+ You can specify its dependencies but without versions.\n\t+ Each module has its own source code here: /src/main/java\n+ **There are top-level modules**:\n\t+ `config`:\n\t\t+ Where most of the configuration is assembled, validated.\n\t\t+ You can find the genesis information.\n\t+ `besu:`\n\t\t+ All the CL arguments are being defined.\n\t\t+ Is where the main method is located.\n+ **There are complementary modules**:\n\t+ `crypto`:\n\t\t+ Everything relative to cryptographic keys.\n\t+ `data types`:\n\t\t+ Data types being used by Besu.\n\t+ `metrics`:\n\t\t+ OpenTelemetry/Prometheus not tight to internal Besu.\n\t+ `ethereum`:\n\t\t+ Is not a module but contains modules :\n\t\t\t+ api :\n\t\t\t\t+ All interaction you want to have with ethereum, world state.\n\t\t\t+ core: \n\t\t\t\t+ Storing date, quorum setup.\n\t+ `evm`:\n\t\t+ EVM behavior\n\t\t+ In this module you can find each opcode operation implementation.\n+ **There are enterprise modules:** \n\t+ enclave, plugin-api, privacy-contracts\n\n### Gradle\n+ gradlew (file) :\n\t+ It is a bash script that will check if gradle is installed or not ( will install the wrapper for you and download the whole distribution)\n\t+ Gradle itself is managed as part of a wrapper that is used by calling this script.\n+ gradle (folder):\n\t+ gradle-wrapper.properties:\n\t\t+ distributionURL : points to the distribution to be used when calling ./gradlew\n\t+ versions.gradle (file):\n\t\t+ It is where all module's versions are defined. It is used by gradlew.\n+ build.gradle (file):\n\t+ plugins:\n\t\t+ `spotless`: Code formatting, check licensing, etc,\n\t\t\t+ Command: `./gradlew spotlessApply`\n\t\t+ `errorprone`: Compliance with best practices in Java.\n\t\t\t+ Command: `./gradlew errorProne`\n\t+ distribution:\n\t\t+ It defines where the building output is left by taking all projects into an application:\n\t\t\t+ .tar .zip distributions. You can see a .tar or .zip under builder/distributions.\n+ build (folder):\n\t+ It's not a module.\n\t+ distributions (folder):\n\t\t+ Location of the Besu distribution.\n\t\t+ If you go deeper to build/distribution/besu-{version}-SNAPSHOT/lib you can see each version of each component and libraries.\n\n### Testing\n+ Unit tests:\n\t+ Each module has its unit testing under src/test/java\n+ Integration tests:\n\t+ Each module has its integration test under src/integration-test/java:\n\t+ Are more rare.\n\t+ Are run outside of the inner internals of the code.\n\t+ Are involved in more expensive runs.\n+ Acceptance tests:\n\t+ Are located under the acceptance-test-module.\n\t+ Runs multiple Beau's nodes to create consensus algorithms between them and performs task adjusting and propagating blocks.\n+ Reference tests:\n\t+ Taken after Ethereum tests, borrowed by the Ethereum foundation.\n\t+ Are the same for all clients: https://github.com/ethereum/tests\n\t+ Are stored in JSON:\n\t\t+ Location: `ethereum/referencetests/`\n+ Other info:\n\t+ JUnit 4\n\n### Development tasks:\n+ Some useful commands:\n\t+ `git pull --recurse-submodules`.\n\t+ `./gradlew spotlessApply`\n\t+ `./gradlew check` (it is run by CI every time you make a PR to Besu repository)\n\t+ `./gradlew assemble`\n\t+ In case you want to connect your MM to your local Besu node, you should run Besu with these options:\n\t\t+ bin/besu --network=dev --rpc-http-enabled --rpc-http-cors-origins=chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn\n\t\t+ RPC URL: http://localhost:8545\n\n### Important classes:\n+ `BesuControllerBuilder`:\n\t+ Manages all the components that are going to be used and needed to setup the client.\n\t+ On the build method you can see if you are building the correct domain object.\n\t+ It returns a BesuController.\n+ `BesuCommand`:\n\t+ Represents the main Besu CLI command.\n+ `ForkIdManager`:\n + Responsible for building and representing the latest fork synchronized.\n\t+ We always need to know where we are in terms of our own chain. This check is done constantly.\n\t+ It is created on EthProtocolManager which is created on BesuControllerBuilder. \n+ `ProtocolSchedule`:\n\t+ Keeps track of all the configuration items as part of a specific range of block numbers for a chain.\n+ `ProtocolSpec`:\n\t+ Let's you configure every aspect of how things work inside the protocol.\n+ `MainnetProtocolSpec`:\n\t+ You will find every spec since frontier.\n\t+ Each new spec is built on top of the previous one and add or change what is necessary.\n+ `MainnetEVMs`:\n\t+ Provides to the EVM the appropriate operations for mainnet hard forks.\n\t+ It is an aggregate state where most of the time you will be adding new features to the spec itself.\n\t+ New operations will be registered here.\n+ `JsonRpcMethodsFactory`:\n\t+ A builder class for RPC methods.\n\t+ From here you can understand how to create new RPC methods.\n\n\n### Important libraries:\n+ https://doc.libsodium.org/:\n\t+ Sodium is a modern, easy-to-use software library for encryption, decryption, signatures, password hashing, and more.\n+ https://github.com/nss-dev/nss:\n\t+ Network Security Services (NSS) is a set of libraries designed to support cross-platform development of security-enabled client and server applications. NSS supports TLS 1.2, TLS 1.3, PKCS #5, PKCS#7, PKCS #11, PKCS #12, S/MIME, X.509 v3 certificates, and other security standards.\n\n## References\n\n+ https://www.youtube.com/watch?v=4pCxwuNRaKg\n+ https://github.com/hyperledger/besu\n+ https://wiki.hyperledger.org/display/besu\n" }, { "path": "docs/wiki/EL/clients/reth.md", "content": "# Reth's architecture\n\n## Overview\n\nThe image represents a rough component flow of Reth's architecture:\n\n\n\n- **Engine**: Similar to other clients, it is the primary driver of Reth.\n- **Sync**: Reth has two modes of sync historical and live\n- **Pipeline**: The pipeline performs historical sync in a sequential manner, enabling us to optimize each stage of the synchronization process. The pipeline is split into stages , where a [stage](https://paradigmxyz.github.io/reth/docs/reth_stages/trait.Stage.html) is a trait that provides us with a function to execute the stage or unwind(undo) it. Currently the pipeline has 12 stages that can be configured, with the first two running separately, the pipeline proceeds top to bottom except when there is a problem encountered then it proceeds to unwind from the issue stage upwards :\n 1. **HeaderStage**: Header verification stage.\n 2. **BodyStage**: Download blocks over P2P.\n 3. **SenderRecoveryStage**: The computation is costly as it retrieves the sender's address from the signature for each transaction in the block's body.\n 4. **ExecutionStage**: The most time-consuming & computationally heavy stage involves taking the sender, transaction, and header and executing them within the REVM. This process generates receipts and change sets. Change sets are data structures that function as hash maps and depict the modifications that occur between accounts inside a single block. In addition, the execution stage operates on a plain state that contains only the addresses and account information in the form of key-value pairs.\n 5. **MerkleStage**(unwind): Skipped during the execution flow, used when unwinding.\n 6. **AccountHashingStage**: Required by the merkle stage,we take the plain state and apply a hashing function to it. Then, we save the resulting hashed account in a database specifically designed for storing accounts.\n 7. **StorageHashingStage**: Similar to above but for storage.\n 8. **MerkleStage**(execute): generates a state root by using the hashes produced by the two preceding stages and then checks if the resulting state root is accurate for the given block.\n 9. **TransactionLookupStage**: Helper stage, allows us to do transaction lookup.\n 10. **IndexStorageHistoryStage**: Enables us to retrieve past data, the execution phase generates the change set, which then indexes the data that existed prior to the execution of the block. Enables us to retrieve the historical data for any given block number.\n 11. **IndexAccountHistoryStage**: Similar to above.\n 12. **FinishStage**:We notify that the engine is now capable of receiving new fork choice updates from the consensus layer's.\n- **BlockchainTree**: When we are nearing the end of the chain during the syncing process, we transition to the blockchain tree. The synchronization occurs close to the tip, when state root validation and execution take place in memory.\n- **Database**: When a block gets canonicalized, it is moved to the database\n- **Provider**: An abstraction over database that provides utility functions to help us avoid directly accessing the keys and values of the underlying database.\n- **Downloader**: Retrieves blocks and headers using peer-to-peer (P2P) networks. This tool is utilized by the pipeline during its initial two stages and by the engine in the event that it need to bridge the gap at the tip.\n- **P2P**: When we approach the tip, we transfer the transactions we have read over P2P to the transaction pool.\n- **Transaction Pool**: Includes DDoS mitigation measures. Consists of transactions arranged in ascending order based on the gas price preferred by the users.\n- **Payload Builder**: Extracts the initial n transactions in order to construct a fresh payload.\n- **Pruner**: Allows us to have a full node.Once the block has been canonicalized by the blockchain tree, we must wait for an additional 64 blocks for it to reach finalization. Once the finalization process is complete, we can be certain that the block will not undergo reorganization. Therefore, if we are operating a full node, we have the option to eliminate the old block using the pruner.\n\n## Storage\n\nReth primarily utilizes the mdbx database. In addition, it offers several valuable abstractions that enhance its underlying database by enabling data transformation, compression, iteration, writing, and querying functionalities. These abstractions are designed to allow reth the option to change its underlying DB, mdbx, with minimal modifications to the existing storage abstractions.\n\n**Codecs**\n\nThis [crate](https://github.com/paradigmxyz/reth/tree/main/crates/storage/codecs) enables the creation of diverse codecs for various purposes. The primary codec utilized in this context is the [Compact trait](https://github.com/paradigmxyz/reth/blob/6d7cd53ad25f0b79c89fd60a4db2a0f2fe097efe/crates/storage/codecs/src/lib.rs#L43), which enables the compression of data, such as unsigned integers by compressing their leading zeros, as well as structures such as access-lists, headers etc.\n\n**DB Abstractions**\n\nThe [database trait](https://github.com/paradigmxyz/reth/blob/e158542d31bf576e8a6b6e61337b62f9839734cf/crates/storage/db/src/abstraction/database.rs#L12) is the fundamental abstraction that provides either read only or read/write access to transactions in the low-level database.\n\nThe [cursor](https://github.com/paradigmxyz/reth/blob/e158542d31bf576e8a6b6e61337b62f9839734cf/crates/storage/db/src/abstraction/cursor.rs#L13) enables iteration over the values in the database and offers a swift method for retrieving transactions or blocks. It is particularly useful when calculating merkle roots, as sequential value access is significantly faster than random seeking. In addition, if we have a large amount of data to write, sorting and writing it is much faster. The cursor allows us to optimize our approach by providing convenient functions for writing either sorted or unsorted data.\n\n**Tables**\n\n| Table | Key | Value | Description |\n| -------------------------- | ----------------------------------- | ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| CanonicalHeaders | BlockNumber | HeaderHash | Stores block number indexed by header hash |\n| HeaderTerminalDifficulties | BlockNumber | CompactU256 | Is responsible for storing the total difficulty value obtained from a block header. Although it is commonly employed in proof-of-work systems, it is currently not in use. |\n| HeaderNumbers | BlockHash | BlockNumber | This is a utility table, it stores block number associated with a header. |\n| Headers | BlockNumber | Header | Stores header bodies. |\n| BlockBodyIndices | BlockNumber | StoredBlockBodyIndices | Stores block indices that contains indexes of transaction and the count of them. This allows us to determine which transaction numbers are included in the block. |\n| BlockOmmers | BlockNumber | StoredBlockOmmers | Stores the uncles/ommers of the block, which are the side blocks that got included (used in proof-of-work) |\n| BlockWithdrawals | BlockNumber | StoredBlockWithdrawals | Stores the block withdrawals. |\n| Transactions | TxNumber | TransactionSignedNoHash | Here the transaction body is stored indexed by the ordinary transaction number. This information includes the total number of transactions and the number of transactions that were executed. Furthermore, it enables us to effortlessly retrieve a solitary transaction. |\n| TransactionHashNumbers | TxHash | TxNumber | Stores the transaction number indexed by the transaction hash. |\n| TransactionBlocks | TxNumber | BlockNumber | Stores the mapping of the highest transaction number to the blocks number. Allows us to fetch the block number for a given transaction number. |\n| Receipts | TxNumber | Receipt | Stores transaction receipts indexed by transaction number. |\n| Bytecodes | B256 | Bytecode | Compiles and stores the bytecode of all smart contracts. There will be multiple accounts with identical bytecode. Therefore, it is necessary to implement a reference counting pointer. |\n| PlainAccountState | Address | Account | Stores the current state of an [Account](https://github.com/paradigmxyz/reth/blob/fb960fb3e45e11c24125ccb4bd93f2e2e21ce271/crates/primitives/src/account.rs#L15), the plain state, indexed by the Account address. The plain state is updated during the execution stage. |\n| PlainStorageState | Address , SubKey = B256 | StorageEntry | Stores the current value of a storage key and the sub-key is the hash of the storage key. Concerning sub-keys: mdbx allows us to dup table (duplicate values inside tables) which can lead a faster access to some values. |\n| AccountsHistory | ShardedKey
| BlockNumberList | Stores pointers to the block changesets that contain modifications for each account key. Each account is associated with a record of modifications, represented as a list of blocks. For example, if we want to retrieve the account balance at block 1 million, we need to determine the next block where the account was modified. If the next modification occurs at block number 1 million and 1, we need to fetch the set of changes for that account from the tables below. |\n| |\n| StoragesHistory | StorageShardedKey | BlockNumberList | Stores pointers to block number changeset with changes for each storage key. This allows us to index the change sets and find the change that happened in the history |\n| AccountChangeSets | BlockNumber, SubKey = Address | AccountBeforeTx | The state of an account is stored prior to any transaction that alters it, such as when the account is created, self-destructed, accessed while empty, or when its balance or nonce is modified. Therefore, for each block number. Therefore, we possess the previous values for each block and account address. |\n| StorageChangeSets | BlockNumberAddress , SubKey = B256 | StorageEntry | Preserves the state of a storage prior to a specific transaction altering it. Therefore, for each block number, account address and sub-key as the storage key, we can obtain the previous storage value. The execution stage modifies both this table and the one above it. These tables are used for the merkle trie calculations, which require the values to be incremental. They are also used for any history tracing performed by the JSON-RPC API. |\n| HashedAccounts | B256 | Account | Stores the current state of an account indexed by keccak256(Address). This table is in preparation for merkleization and calculation of state root. This and the table below are used by the merkle trie, for the first calculation of the merkle trie we need sorted hashed addresses |\n| HashedStorages | B256, SubKey = B256 | StorageEntry | Stores the current storage values indexed by keccak256(Address) and the sub-key as the hash of storage key keccak256(key). Like above useful for merkleization as the hashed addresses/keys are sorted. |\n| AccountsTrie | StoredNibbles | StoredBranchNode | Stores the current state's Merkle Patricia Tree. |\n| StoragesTrie | B256 , SubKey = StoredNibblesSubKey | StorageTrieEntry | From HashedAddress => NibblesSubKey => Intermediate value. This and the above table stores the nodes needed for merkle trie calculation |\n| TransactionSenders | TxNumber | Address | Stores the transaction sender for each transaction. It is needed to speed up execution stage and allows fetching the signer without doing the computationally expensive transaction signer recovery |\n| StageCheckpoints | StageId | StageCheckpoint | Stores the highest synced block number and stage-specific checkpoint of each stage. |\n| StageCheckpointProgresses | StageId | Vec | Stores arbitrary data to keep track of a stage first-sync progress. This and the above table allows us to know where the stage stopped and to determine what to do next. |\n| PruneCheckpoints | PruneSegment | PruneCheckpoint | Records the maximum pruned block number and the pruning mode for each segment of the pruning process. This enables us to determine the extent to which we have pruned our data, involving the elimination of change sets and their corresponding indexes to eliminate historical data, leaving only the most recent data to be retrieved i.e. fetching the tip. |\n| VersionHistory | u64 | ClientVersion | Stores the history of client versions that have accessed the database with write privileges indexed by unix timestamp seconds. |\n" }, { "path": "docs/wiki/EL/data-structures.md", "content": "# Data Structures in Execution Layer\n\nThe execution client stores the current state and historical blockchain data. In practice, the Ethereum data are stored in trie like structures, mainly Merkle Patricia Tree.\n\n## RLP\n\n[Wiki - RLP](/wiki/EL/RLP.md)\n\n## Primer on Merkle Tree\n\nMerkle tree is a hash-based data structure which is very efficient at data integrity and verification. It is a tree based structure where the leaf nodes hold the data values and each non-leaf node is a hash of its child nodes.\n\nA Merkle tree stores all the transactions in a block by producing a digital fingerprint of the entire set of transactions. It allows the user to verify whether a transaction is included in a block or not. Merkle trees are created by repeatedly calculating hashing pairs of nodes until there is only one hash left. This hash is called the **Merkle Root**, or the Root Hash. The Merkle Trees are constructed in a bottom-up approach.\n\nIt is important to note that Merkle trees are in a **binary tree**, so it requires an even number of leaf nodes. If there is an odd number of transactions, the last hash will be duplicated once to create an even number of leaf nodes.\n\nMerkle Trees provide a tamper-proof structure to store transaction data. Hash functions have an Avalanche Effect i.e. a small change in the data will result in a huge change in the resulting hash. Hence, if the data in the leaf nodes are ever modified, the Root Hash will not match the expected value.\nYou can try out [SHA-256](https://emn178.github.io/online-tools/sha256.html) hashing function yourself as well.\nTo learn more about Hashing, you may refer to [this](https://github.com/ethereumbook/ethereumbook/blob/develop/04keys-addresses.asciidoc).\n\nMerkle Root is stored in the **Block Header**. Read more about the structure of a Block inside Ethereum (_will be linked this to relevant doc once its ready_)\n\nThe main parent node is called Root, hence the hash inside is Root Hash. There is an infinitesimally small chance(1 in 1.16x10^77 for a single SHA-256 hash) to create two different states with the same root hash, and any attempt to modify state with different values will result in a different state root hash.\n\nThe image below depicts a simplified version of the working of a Merkle Tree:\n\n- The leaf nodes contain the actual data(for simplicity, we have taken numbers).\n- Every non-leaf node is a hash of its children.\n- The first level of non-leaf nodes contains the Hash of its child leaf nodes.\n `Hash(1,2)`\n- The same process continues till we reach the top of the tree, which the Hash of all the previous Hashes.\n `Hash[Hash[Hash(1,2),Hash(3,4)],Hash[Hash(5,6),Hash(7,8)]]`\n\nMore on [Merkle Trees in Ethereum](https://blog.ethereum.org/2015/11/15/merkling-in-ethereum)\n\n![Merkle Tree](../../images/merkle-tree.jpg)\n\n## Primer on Patricia Tree\n\nPatricia Tries (also called Radix tree) are n-ary trees that, unlike Merkle Trees, are used for efficient storage of data instead of verification.\n\nSimply put, Patricia Tries is a tree data structure where:\n - The number of children of each node is at most the radix r of the radix trie, where r = 2^x for some integer x ≥ 1.\n - Unlike regular trees, edges can be labeled with sequences of characters, making the structure much more space-efficient.\n - Each node that is the only child is merged with its parent, which is also more space efficient compared to a Merkle Tree for example.\n\nA simple diagram will display how Patricia Trie traversal works. Suppose we are searching for the value associated with the key \"romulus\". The value will be held at the leaf node.\n- Unlike a regular trie, where data might be stored in intermediary nodes, Patricia Tries store values only in leaf nodes. This improves space efficiency and makes cryptographic verification easier.\n![Patricia Trie](../../images/data-structures/patricia-trie.png)\n\n1. Start at the root node, which serves as the entry point, and contains \"r\", which will be the starting prefix for all stored keys.\n2. Follow the edge labels (compressed path representation) such as \"om\". Patricia Trie merges common prefixes into a single edge instead of how standard tries store each character in a separate node. This prefix compression makes the trie more compact leading to storage efficiency and efficient lookups.\n3. Continue traversing until a leaf node for the key \"romulus\" is reached to obtain the value.\n\n## Merkle Patricia Trie\n\nNow that we have a fair understanding of both Merkle Trees and Patricia Tries, we can dive into Ethereum's primary data structure for storing the execution layer state, the **Merkle Patricia Trie** (pronounced \"try\"). It is named so, since it is a Merkle tree that uses features of PATRICIA (Practical Algorithm To Retrieve Information Coded in Alphanumeric), and because it is designed for efficient data retrieval of items that comprise the Ethereum state.\n\n- From Merkle Trees, it inherits the cryptographic verification properties where each node contains hashes of its children.\n- From Patricia Tries, it inherits efficient key-value storage and retrieval capabilities through prefix-based node organization.\n\nThere are three types of nodes within the MPT:\n\n- **Branch Nodes**: A branch node consists of a 17-element array, which includes one node value and 16 branches. This node type is the primary mechanism for branching and navigating through the trie.\n- **Extension Nodes**: These nodes function as optimized nodes within the MPT. They come into play when a branch node has only one child node. Instead of duplicating the path for every branch, the MPT compresses it into an extension node, housing both the path and the child's hash.\n- **Leaf Nodes**: A leaf node represents a key-value pair. The value is the MPT node's content, while the key is the node's hash. Leaf nodes store specific key-value data.\n\nEvery single node has a hash value. The node's hash is calculated as the SHA-3 hash value of its contents. This hash also acts as a key to refer that specific node.\nNibbles serve as the distinguishing unit for key values in the MPT. It represents a single hexadecimal digit. Each trie node can branch out to as many as 16 offshoots, ensuring a concise representation and efficient memory usage.\n\nThe following diagram illustrates how traversal and hashing work together in the MPT. As an example of data retrieval from a leaf node, let's obtain the value `hi` using the key `11110AA`.\n\n![Merkle Patricia Trie Diagram](../../images/data-structures/merkle-patricia-trie.png)\n\n### 1. Start at the Root (Extension Node in this Scenario)\n- The key we are searching for is `11110AA`.\n- The root node is an **extension node** because all keys in this trie share the common prefix `1111`.\n - Instead of storing `1111` across multiple branch nodes, it is compressed into a single edge, making the lookup more efficient.\n- The extension node's hash is the root hash and is computed as:\n `N1 = hash(RLP(HP(prefix, path=1111), N2))`.\n - Since `N1` depends on `N2`, any change in `N2` would alter the root hash.\n\n### **2. Navigate to the Branch Node (N2)**\n- After `1111`, the next hex character in our key (`11110AA`) is `0`, so we take the `0` branch from `N2`, which leads us to **leaf node (`N5`)**.\n- The branch node’s hash is computed as:\n `N2 = hash(RLP(N5, ...))`.\n - Since `N2` depends on `N5`, any modification to `N5` affects `N2`, which in turn affects `N1`.\n\n### **3. Arrive at the Leaf Node (N5)**\n- `N5` is a **leaf node** where the search ends.\n- The leaf node stores:\n - **Prefix**: `AA` (the remaining unique part of the key after `11110`).\n - **Value**: `\"hi\"`.\n\n> This [excellent post](https://easythereentropy.wordpress.com/2014/06/04/understanding-the-ethereum-trie/) explains PATRICIA trie in detail along with a [python implementation](https://github.com/ebuchman/understanding_ethereum_trie) for practice.\n\n# Ethereum\n\nEthereum state is stored in four different modified Merkle Patricia Tries (MMPTs):\n\n- Transaction Trie\n- Receipt Trie\n- World State Trie\n- Account State Trie\n\n![Tries](../../images/tries.png)\n\nAt each block there is one transaction, receipt, and state trie which are referenced by their root hashes in the block Header.\nFor every contract deployed on Ethereum there is a storage trie used to hold that contract's persistent variables, each storage trie is referenced by their root hash in the state account object stored in the state trie leaf node corresponding to that contract's address.\n\n## Transaction Trie\n\nThe Transaction Trie is a data structure responsible for storing all the transactions within a specific block. Every block has its own Transaction Trie, corresponding to the respective transactions that are included in that block.\nEthereum is a transaction based state machine. This means every action or change in Ethereum is due to a transaction. Every block is made up of a block header and a transaction list(among other things). Thus, once a transaction is executed and a block is finalized the transaction trie for that block can never be changed.(in contrast to the World State trie).\n\n![Merkle Tree](../../images/transaction-trie.png)\n\nA transaction is mapped in the trie so that the key is a transaction index and the value is the transaction T . Both the\ntransaction index and the transaction itself are RLP encoded. It compose a key-value pair, stored in the trie:\n`𝑅𝐿𝑃 (𝑖𝑛𝑑𝑒𝑥) → 𝑅𝐿𝑃 (𝑇)`\n\nSee the [summary](/wiki/EL/el-data-structures-summary?id=transaction-trie) for the field definitions of the different transaction types in the transaction trie.\n\n## Receipt Trie\n\nThe Receipt Trie is similar to the Transaction Trie in that it is a block level data structure, and each leaf of the trie represents some RLP-encoded data related to the transaction. However, the Receipt Trie is used to verify that the instructions in each transaction were actually executed. This verification data is held in the leaf node and contains a few fields, which are described in the [transaction anatomy](/wiki/EL/transaction.md#receipts) section of the wiki.\n\nIn this section, we will focus on the `Receipt Trie` itself.\n\nThe `ReceiptRoot` of the `Receipt Trie` is the keccak 256-bit hash of the root node.\n\nHere is a simple diagram of a Receipt Trie, which follows the Merkle Patricia Trie flow for value lookups.\n![Receipt Tree](../../images/data-structures/receipt-trie.png)\n\nIf you know the index of a transaction in a block, you can easily find it's corresponding receipt in the `Receipt Trie`. This is because the transaction's position (index) in a block is used as the key in the `Receipt Trie`'s leaf node containing the receipt for that transaction. Using the transaction's index as the receipt's key provides some nice benefits such as avoiding needing to calculate or look up transaction hashes to locate receipts in the trie.\n\nThe primary role of the receipts trie is to provide a canonical, authenticated record of transaction results, primarily used for indexing historical data without having to re-execute transactions. During snap sync, full nodes download block bodies — which contain both transactions and their corresponding receipts — and locally reconstruct the receipt trie for each block. The reconstructed trie is then validated against the receiptsRoot in the block header. Snap sync avoids the need for full nodes to re-execute historical transactions solely to regenerate receipts, significantly accelerating the sync process.\n\nWhile receipts enable light clients to verify transaction outcomes via Merkle proofs against the receiptsRoot, this is a secondary use. Since light clients only store block headers, they rely on full nodes to query for these proofs and `receiptsRoot`. This structure allows light clients to independently verify the legitimacy of the data without storing the full transaction history.\n\nSee the [summary](/wiki/EL/el-data-structures-summary?id=receipts-trie) for the field definitions of receipts.\n\n## World State Trie\n\nThe **World State Trie** is the core data structure that represents Ethereum's current state. It maps the keccak-256 hashed 20 byte account addresses to their RLP encoded states utilizing a **Merkle Patricia Trie** where the key-value pairs are stored as byte arrays to byte arrays in the leaves of the trie.\n\nAccounts can be categorized as either smart contract accounts with code or Externally Owned Accounts (EOAs) associated with private keys. EOAs are used to initiate transactions with other EOAs or smart contract accounts, triggering the execution of the associated contract code.\n\nThe **World State Trie** is not stored in the chain, but the 32-byte keccak-256 **state root** of the trie is stored in every block header after all transactions in a block have been processed. The **state root** is used as a cryptographic commitment for the entire system state since it's cryptographically dependent on all the data in the trie. For example, a node can prove an account's existence given the **state root** and a **Merkle proof** containing the account and it's sibling nodes needed to recreate the **state root**. Furthermore, the **state root** in each block anchors Ethereum’s consensus: any node can independently compute or verify this root by applying the block’s transactions to the previous state trie.\n\nBelow is a simplified diagram of the ***World State Trie***.\n\n![Merkle Tree](../../images/eth-tries.png)\n\nLet's traverse the trie to find the account with a **45 ETH** balance. The key for this account is shown as `a711355`, meaning these seven hex digits direct us from the root node down to the leaf node.\n\n> This short key `a711355` is just for demonstration. Actual addresses in Ethereum get hashed (32 bytes) and thus typically yield up to 64 nibbles in the trie. But the traversal steps are the same—each nibble selects the next branch/extension node until we arrive at the leaf node storing the final account data.\n\n1. **Key to Nibbles**\n - The key string `a711355` represents seven hex digits: `a`, `7`, `1`, `1`, `3`, `5`, `5`.\n - Each digit is a nibble (4 bits), so the entire key is a sequence of seven nibbles.\n\n2. **Path Through the Trie**\n - **Extension node** at the root might store a prefix like `a7`, consuming the first two nibbles.\n - **Branch node** follows, allowing navigation by each subsequent nibble (`1`, `1`, `3`, `5`, `5`).\n\n3. **Leaf Node**\n - Consuming all nibbles brings us to the **leaf node**. In our simplified example, its stored value is **“45 ETH”**.\n - In Ethereum’s real MPT, this leaf node actually holds the RLP-encoded account object `[nonce, balance, storageRoot, codeHash]`.\n\n\nSee the [summary](/wiki/EL/el-data-structures-summary?id=state-trie) for the field definitions of accounts in the state trie.\n\n### Persistent Storage\n\nThe **World State Trie** is a living structure that evolves with each block, unlike the transaction and receipt tries which are rebuilt from scratch for every block. Ethereum operates as a state machine, where the current state is updated by executing transactions in a block. Each node must track this current state to verify transactions and update it accordingly. Therefore, intermediate states exist during block processing, but nodes retain only the final post-block state. A full node will keep track of the current state of the **World State Trie** and enough trie nodes required to rewind during a re-org. Archival nodes will keep track of all previous states since genesis.\n\nIn summary, Ethereum's world state is a secure and verifiable representation of the current state of all accounts at a given block height.\n\n## Storage Trie\n\nIn the previous section, we described how each account leaf in the **World State Trie** contains a `storageRoot`, which is the keccak-256 hash of the root node of a separate Merkle Patricia Trie, the **Storage Trie**. This trie is not embedded in the **World State Trie** but referenced via the `storageRoot`, enabling storage to be updated and proven independently while still contributing to the global state root.\n\nThe **Storage Trie** represents a contract’s persistent state as a mapping of 256-bit storage slots indices (keys) to 256-bit RLP-encoded values. Each such key-value pair is referred to as a storage slot. Like the **World State Trie**, it uses a secure key scheme where each slot index is hashed with keccak-256 before insertion. This prevents attackers from crafting keys that cause long traversal paths or highly unbalanced trie structures, which could otherwise be exploited for DOS attacks by inducing excessive computation during trie lookups or updates.\n\n> While high-level languages (e.g., Solidity) define how contract variables are laid out across storage slots, this layout abstraction originates in the language itself. The execution layer merely implements this abstraction. At the EL layer level, the trie treats all slots as uniform key-value entries.\n\nEach account has its own **Storage Trie**, which starts as an empty trie. The trie is modified via the `SSTORE` opcode and read via `SLOAD` during contract execution. For EOAs, the storage trie remains empty and is never accessed. These opcodes are defined in the EVM and described further in the [EVM documentation’s storage section](wiki/EL/evm.md#evm-data-locations).\n\nTo retrieve the value of a storage slot (e.g., index `0x00`) from the leaf of **Storage Trie**:\n1. RLP-encode the slot index and keccak-256 hash the result.\n2. Use the resulting hash as a key to traverse the trie, starting at `storageRoot`.\n3. Follow the path using the nibbles of the hash to reach the corresponding leaf node.\n4. Extract and decode the RLP-encoded value stored at the leaf.\n\nProofs can be constructed from the nodes along this path to verify a slot’s value against the `storageRoot`.\n\nIn summary, the **Storage Trie** is fundamental to Ethereum’s account model, providing each contract with its own isolated and verifiable storage space. Unlike the **World State Trie**, which maps addresses to account metadata, the **Storage Trie** maintains contract-specific key-value state across blocks.\n\n## Future Implementations\n\n## Verkle Trees\n\n[Verkle tree](https://verkle.info/) is a new data structure that is being proposed to replace the current Merkle Patricia Trie. Named by combining the \"Vector commitment\" and \"Merkle Tree\", it is designed to be more efficient and scalable than the current MPT. It is a trie-based data structure that replaces the heavy witness used in the MPT with a lightweight witness. Verkle trees are the key part of The Verge upgrade of [Ethereum Roadmap](https://ethereum.org/en/roadmap/#what-about-the-verge-splurge-etc). They can enable [stateless](https://ethereum.org/en/roadmap/statelessness/#statelessness) clients to be more efficient and scalable.\n\n### Structure of Verkle Tree\n\nThe layout structure of a Verkle tree is just like a MPT but with different base of the tree i.e. number of children. Just like [MPT](https://ethereum.org/en/developers/docs/data-structures-and-encoding/patricia-merkle-trie/#optimization) it has root node, inner nodes, extension nodes and leaf nodes. There a slight difference in the key size, on which the tree is made. MPT uses 20 byte key which Verkle tree uses 32 byte key in which the 31 bytes are used as a stem of the tree while last 1 byte is used for storage with almost the same stem address or neighboring code chunks (opening the same commitment is cheaper). Also due to the fact that while computing the witness data the algorithms take 252 bit as field element so it is convenient to use 31 bytes as a suffix of the tree. Using this, the stem data can commit to two difference commitments ranging from 0-127 and 128-255, aka lower value and upper value of the same key, thus covering the whole suffix space. For more on this refer [here](https://blog.ethereum.org/2021/12/02/verkle-tree-structure).\n\n![Verkle Tree](../../images/verkle_tree_structure.png)\n\n### Key differences between MPT and Verkle Tree\n\nA Merkle/MP tree has a lot of depth since the tree structure is binary (2/16-ary tree) at every node. This means that the witness data for a leaf node is the path from the root to the leaf. Due to the fact that sibling hash data is also required at each level, this makes the witness data very large for a large tree. A Verkle tree has a lot of width since the tree structure is n-ary at every node. This means that the witness data for a leaf node is the path from the leaf to the root. This can be very small for a large tree. Currently the Verkle tree is proposed to have 256 children per node. More on this [here](https://ethereum.org/en/roadmap/verkle-trees/)\n\nThe intermediate nodes of Merkle/MP tree are hashes of the children. The nodes of a Verkle tree carry a special type of hash called \"vector commitments\" to commit to their children. This means that the witness data for a leaf node in a Verkle tree is the commitment of the children of the path from the leaf to the root. On top of this a proof is computed by aggregating the commitments which makes the verification process very compact. More on [Proof System](https://dankradfeist.de/ethereum/2021/06/18/pcs-multiproofs.html?ref=hackernoon.com).\n\n### Why Verkle Trees?\n\nTo make a client stateless it is essential that to validate a block, client should not have to store the entire/previous blockchain state. The incoming block should be able to provide the client with the necessary data to validate the block. This extra proof data are called _witness_ enabling a stateless client validating the data without the full state.\nUsing the information inside the block, client should also be able to maintain/grow a local state with each incoming block. Using this a client guarantees that for the current block (and succeeding ones that it validates) the state transition is correct. It doesn't guarantee that the state is correct for the previous blocks that the current block refers to because block producer can build on an invalid or non-canonical block.\n\nVerkle trees are designed to be more efficient in terms of storage and communication cost. For a 1000 leaves/data, a binary Merkle Tree takes around 4MB of witness data, Verkle tree reduces it to 150 kB. If we include the witness data in the block then it will not impact the blocksize that much but it would enable the stateless clients to be more efficient and scalable. Using this the stateless client will be able to trust the computation done without having to store the entire state.\n\nThe transition to new verkle tree database poses a major challenge. To securely create the new verkle data, clients needs to generate them from the existing MPT which takes a lot of computation and space. Distribution and verification of the verkled database is currently being researched.\n\n## Resources\n\n- [Merkle in Ethereum](https://blog.ethereum.org/2015/11/15/merkling-in-ethereum)\n- [More on Merkle Patricia Trie](https://ethereum.org/developers/docs/data-structures-and-encoding/patricia-merkle-trie)\n- [More on Verkle Tree](https://notes.ethereum.org/@vbuterin/verkle_tree_eip#Simple-Summary)\n- [Verge transition](https://notes.ethereum.org/@parithosh/verkle-transition)\n- [Implementing Merkle Tree and Patricia Trie](https://medium.com/coinmonks/implementing-merkle-tree-and-patricia-trie-b8badd6d9591) • [archived](https://web.archive.org/web/20210118071101/https://medium.com/coinmonks/implementing-merkle-tree-and-patricia-trie-b8badd6d9591)\n- [Radix Trie](https://en.wikipedia.org/wiki/Radix_tree#) • [archived](https://web.archive.org/web/20250105072609/https://en.wikipedia.org/wiki/Radix_tree)\n- [Radix Trie Diagram](https://samczsun.com/content/images/2021/05/1920px-Patricia_trie.svg-1-.png) • [archived](https://web.archive.org/web/20231209235318/https://samczsun.com/content/images/2021/05/1920px-Patricia_trie.svg-1-.png)\n- [Merkle Patricia Trie Diagram](https://www.researchgate.net/publication/353863430/figure/fig2/AS:1056193841741826@1628827643578/Ethereum-Encoded-Merkle-Patricia-Trie.png)\n- [Merkle Patricia Trie Diagram Explanation](https://www.researchgate.net/publication/353863430_Ethereum_Data_Structures)\n- [Receipts Trie Including Diagram](https://medium.com/coinmonks/ethereum-data-transaction-receipt-trie-and-logs-simplified-30e3ae8dc3cf) • [archived](https://web.archive.org/web/20250000000000/https://medium.com/coinmonks/ethereum-data-transaction-receipt-trie-and-logs-simplified-30e3ae8dc3cf)\n- [Ethereum Data Structures](https://arxiv.org/pdf/2108.05513/1000) • [archived](https://web.archive.org/web/20240430050355/https://arxiv.org/pdf/2108.05513/1000)\n- [DevP2P Wire Protocol](https://github.com/ethereum/devp2p/blob/master/caps/eth.md) • [archived](https://web.archive.org/web/20250328095848/https://github.com/ethereum/devp2p/blob/master/caps/eth.md)\n- [Snap Sync](https://geth.ethereum.org/docs/fundamentals/sync-modes) • [archived](https://web.archive.org/web/20250228111146/https://geth.ethereum.org/docs/fundamentals/sync-modes)\n- [More on Merkle Patricia Trie](https://ethereum.org/developers/docs/data-structures-and-encoding/patricia-merkle-trie)\n- [Ethereum Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf) • [archived](https://web.archive.org/web/20250228142704/https://ethereum.github.io/yellowpaper/paper.pdf)\n- [State Trie Keys](https://medium.com/codechain/secure-tree-why-state-tries-key-is-256-bits-1276beb68485#:~:text=This%20is%20because%20when%20Ethereum,the%20secure%20tree%20in%20Ethereum) • [archived](https://web.archive.org/web/20230524084537/https://medium.com/codechain/secure-tree-why-state-tries-key-is-256-bits-1276beb68485)\n" }, { "path": "docs/wiki/EL/devp2p.md", "content": "# DevP2P\n\nThis section will cover the networking protocol used by the Execution Layer (EL).\nFirst, as it is referred in the [networking section](../dev/cs-resources.md?id=networking), focusing on the transport layer, the two protocols used by DevP2P are TCP (Transmission Control Protocol) and UDP (User Datagram Protocol).\nBoth protocols are used to send data over the internet, but they have different characteristics. Just as Tanenbaum points it out (2021),TCP is a connection-oriented protocol, which means that it establishes a connection between the sender and the receiver before sending data.\nIt is reliable because it ensures that the data is delivered in the correct order and without errors. UDP is a connectionless protocol, which means that it does not establish a connection before sending data.\nIt is faster than TCP because it does not have to establish a connection before sending data, but it is less reliable because it does not ensure that the data is delivered in the correct order or without errors.\n\n![img.png](../../images/el-architecture/tcpudp.png)\n\n\n## EL's networking specs\nAs a peer-to-peer network Ethereum implies a series of rules to enable communication between its participant nodes. This section cover an explanation of which are those rules and how they are implemented in the EL.\nConsidering each Ethereum node is built upon two different components: the execution client and the consensus client, each one of them has its own peer-to-peer network with its own purpose.\nThe execution client is responsible for gossiping transactions, while the consensus client is responsible for gossiping the blocks.\n> There are historical reasons for different CL/EL p2p networks and their underlying technologies. Ethereum was originally built on devp2p as its own custom networking stack. By the time Beacon Chain was created, libp2p was ready for production and adopted there.\nKeeping this in mind, the scope of the EL network covers two different stacks working in parallel: the discovery one, and the information transport itself. \nThe discovery stack is responsible for finding the node peers, while the transport stack is responsible for sending and receiving messages between them.\nTaking the computer networks background into account, then we can infer that the discovery stack relies on the UDP protocol, while the information exchange stack relies on the TCP protocol.\nThe reason behind this is that the information exchange requires a reliable connection between the nodes,\nso they can be able to both confirm the connection before sending the data and have a way to ensure that the data is delivered in the correct order and without errors (or at least to have a way to detect and correct them),\nwhile the discovery process does not require the reliable connection, since it is enough to let other knows that the node is available to communicate.\n\n### Discv protocol (Discovery)\nThe process of how the nodes find each other in the network starts with [the hard-coded bootnodes listed in the specification](https://github.com/ethereum/go-ethereum/blob/master/params/bootnodes.go).\nThe bootnodes are nodes that are known by all the other nodes in the networks (both Mainnet and testnets), and they are used to bootstrap the discovery peers process.\nUsing the Kademlia-like DHT (Distributed Hash Table) algorithm, the nodes are able to find each other in the network by referring to a routing table where the bootnodes are listed.\nThe TLDR of the Kademlia is that it is a peer-to-peer protocol that enables nodes to find each other in the network by using a distributed hash table, as Leffew mentioned in his article (2019).\n\nThat is to say, the connection process starts with a PING-PONG game where the new node send a PING message to the bootnode, and the bootnode responds with a PONG hashed message.\nIf both messages match, then the new node is able to bond with the bootnode. In addition to this, the new node sends a FIND-NEIGHBOURS request to the bootnode, so it can receive a list of neighbours that able to connect with,\nso it can repeat the PING-PONG game with them and bond with them as well.\n\n![img.png](../../images/el-architecture/peer-discovery.png)\n\n#### Wire protocol\nThe PING/PONG game is better known as the wire subprotocol, and it includes the next specifications:\n\n**PING packet structure**\n```\nversion = 4\nfrom = [sender-ip, sender-udp-port, sender-tcp-port]\nto = [recipient-ip, recipient-udp-port, 0]\npacket-data = [version, from, to, expiration, enr-seq ...]\n```\n\n**PONG packet structure**\n```\npacket-data = [to, ping-hash, expiration, enr-seq, ...]\n```\n\nThe packet-data is wrapped in 1280 bytes UDP datagram alongside with the header:\n```\npacket-header = hash || signature || packet-type\nhash = keccak256(signature || packet-type || packet-data)\nsignature = sign(packet-type || packet-data)\npacket = packet-header || packet-data\n```\n\n**FindNode packet structure** (called FIND-NEIGHBOURS above)\n```\npacket-data = [target, expiration, ...]\n```\nWhere the target is a 64-byte secp256k1 node's public key.\n\n**Neighbours packet structure**\n```\npacket-data = [expiration, neighbours, ...]\nneighbours = [ip, udp-port, tcp-port, node-id, ...]\n```\nWhere the neighbours are the list of 16 nodes that are able to connect with the new node.\n\n**ENR Request packet structure**\n```\npacket-data = [expiration]\n```\n\n**ENR Response packet structure**\n```\npacket-data = [request-hash, ENR]\n```\nWhere ENR is the Ethereum Node Record, a standard format for connectivity for nodes. Which it is explained below.\n\n---\n\n\nThis Kademlia-like protocol includes the routing table, which keeps information about other nodes in the neighbourhood consisting of *k-buckets* (where *k* is the number of nodes in the bucket, currently defined as 16).\nWorth mentioning that all the table entries are sorted by *last seen/least-recently seen* at the head, and most-recently seen at the tail.\nIf one of the entities has not been responded to in 12 hours, it is removed from the table, and the next encounter node is added to the tail of the list.\n\n\n#### Discovery Protocols (Discv4 & Discv5)\nCurrently, most execution clients have adopted the [Discv5 protocol](https://github.com/ethereum/devp2p/blob/master/discv5/discv5.md) for the discovery process, while some are still transitioning from [Discv4](https://github.com/ethereum/devp2p/blob/master/discv4.md). Below is a table categorizing execution clients based on their Discv5 support status (as of May 2025).\n\n| **Category** | **Execution Clients** |\n|---------------------|-------------------------------------------|\n| **Supports Discv5** | [Geth](https://github.com/search?q=repo%3Aethereum%2Fgo-ethereum%20discv5&type=code), [Nethermind](https://github.com/search?q=repo%3ANethermindEth%2Fnethermind+discv5&type=issues), [Reth](https://github.com/search?q=repo%3Aparadigmxyz%2Freth%20discv5&type=code) |\n| **Pending Migration** | [Besu](https://github.com/search?q=repo%3Ahyperledger%2Fbesu+discv5&type=issues), [Ethereumjs](https://github.com/ethereumjs/ethereumjs-monorepo/tree/master/packages/devp2p), [Erigon](https://github.com/search?q=repo%3Aerigontech%2Ferigon+discv4&type=code) |\n##### Discv4\nA structured, distributed system that allows Ethereum nodes to discover peers without central coordination. \n\n- **Node Identities** \n - Each node is identified by a secp256k1 key pair. \n - The public key serves as the node’s unique identifier (Node ID). \n - Distance between nodes is computed using XOR of hashed public keys. \n\n- **Node Records (ENR)** \n - Nodes store and share connection details using Ethereum Node Records (ENRs). \n - The \"v4\" identity scheme is used to verify node authenticity. \n - Peers can request a node’s latest ENR via an **ENRRequest** packet. \n\n- **[Kademlia Table](https://en.wikipedia.org/wiki/Kademlia)** \n - Nodes maintain a **routing table** with 256 **[k-buckets](https://en.wikipedia.org/wiki/Kademlia#Fixed-size_routing_tables)** (each holding up to 16 entries). \n - A bucket stores nodes within a specific distance range (e.g., `[2^i, 2^(i+1))`). \n - Nodes are sorted by last-seen time, ensuring stale nodes are replaced when the table is full. \n\n- **Endpoint Verification (Proof-of-Participation)** \n - Prevents amplification attacks by verifying nodes before responding to queries. \n - A node is considered verified if it has sent a valid **Pong** response to a recent **Ping** request. \n\n- **Recursive Lookup Algorithm** \n - Finds the `k` (typically 16) closest nodes to a target. \n - The search begins by querying a small, selected subset of the closest known nodes (`α`, often set to 3). \n - The lookup is **iterative**, querying new nodes found in previous steps until no closer nodes are discovered. \n\n- **Wire Protocol & Message Types** \n - Messages are sent over **UDP** . \n - Each packet contains a header (`hash`, `signature`, `packet-type`) followed by encoded data. \n - Core message types: \n - **Ping (0x01):** Verify node availability. \n - **Pong (0x02):** Response to a Ping, proving reachability. \n - **FindNode (0x03):** Request nodes near a target ID. \n - **Neighbors (0x04):** Reply to FindNode with closest known peers. \n - **ENRRequest (0x05):** Request a node’s latest ENR. \n - **ENRResponse (0x06):** Provide an ENR in response to a request. \n\n\n##### Discv5\n\nDiscv5 is Ethereum’s improved decentralized peer discovery protocol, building upon the foundation of Discv4 with enhanced service discovery and security mechanisms. Like its predecessor, Discv5 enables nodes to locate and connect with peers in a decentralized manner, without relying on centralized directories. However, it introduces encrypted communication, service discovery, and adaptive routing.\n\nInspired by the Kademlia DHT, discv5 differs by storing only signed node records (ENR) instead of arbitrary key-value pairs. This ensures authenticity and integrity in peer discovery.This ensures authenticity and integrity in peer discovery while maintaining flexibility for protocol extensions.\n\n- **Ethereum Node Records (ENR)**\n - Each node maintains an **Ethereum Node Record (ENR)**, storing **connectivity details, cryptographic keys, and metadata**.\n - ENRs are signed, self-contained, and update dynamically.\n - Peers can request the latest ENR using an **ENRRequest packet**.\n\n- **Encrypted Wire Protocol**\n - Uses **[AES-GCM encryption](https://en.wikipedia.org/wiki/AES-GCM-SIV)** for confidentiality and authenticity.\n - Establishes **session keys via ECDH** ([Elliptic Curve Diffie-Hellman](https://en.wikipedia.org/wiki/Elliptic-curve_Diffie%E2%80%93Hellman)).\n - Implements a **WHOAREYOU challenge-response mechanism** to prevent spoofing.\n\n- **Kademlia-Based Routing & Node Table**\n - Nodes maintain a **routing table (k-buckets)** with peers sorted by XOR distance.\n - The lookup process recursively queries the closest known nodes.\n - The protocol supports **adaptive routing and self-healing**.\n\n- **Recursive Node Lookup & Peer Discovery**\n - Nodes find peers through **iterative Kademlia-based lookups**.\n - Uses parallelized queries to **increase resilience against adversaries**.\n - Bootstrap nodes facilitate new node entry.\n\n- **Topic Advertisement & Service Discovery**\n - Nodes advertise services via **topic advertisements**.\n - Searches for nodes providing a service use **Kademlia lookups within a topic radius**.\n - Adaptive **radius estimation** ensures efficient searches.\n\n- **Wire Protocol & Message Types**\n | **Message** | **Function** |\n |---------------|-------------|\n | **Ping** (0x01) | Checks if a node is alive. |\n | **Pong** (0x02) | Response to Ping, confirms reachability. |\n | **FindNode** (0x03) | Requests peers near a target ID. |\n | **Nodes** (0x04) | Responds to FindNode with known peers. |\n | **ENRRequest** (0x05) | Requests the latest ENR of a node. |\n | **ENRResponse** (0x06) | Provides the requested ENR. |\n | **WhoAreYou** (0x07) | Authentication challenge. |\n | **Handshake** (0x08) | Establishes encrypted sessions. |\n | **TalkReq / TalkResp** (0x09/0x0A) | Enables custom application protocols. |\n\n\n\n##### Comparison: Discv4 vs. Discv5\n| Feature | Discv4 | Discv5 |\n|-------------------------|--------|--------|\n| **Node Records** | Basic ENR | Extensible ENR with metadata |\n| **Security** | Plaintext | AES-GCM encrypted |\n| **Handshake** | None | Secure session establishment |\n| **Service Discovery** | Limited | Topic-based lookup |\n| **Extensibility** | Static | Supports multiple identity schemes |\n| **Clock Dependence** | Required | Eliminated |\n| **Scalability** | Moderate | Optimized for large networks |\n\n### ENR: Ethereum Node Records\nThe ENR is a standard format for p2p connectivity, which was originally proposed in the [EIP-778](https://eips.ethereum.org/EIPS/eip-778).\nA node record contains the node's network endpoints, such as the IP address and port, as well as the node's public key and the sequence number of the record.\n\nThe record content structure is as follows:\n\n| Key | Value |\n| --- |-------------------------------------------|\n| id | id scheme, e.g \"v4\" |\n| secp256k1 | compressed public key, 33 bytes |\n| ip | IPv4 address, 4 bytes |\n| tcp | TCP port, big endian integer |\n| udp | UDP port, big endian integer |\n| ip6 | IPv6 address, 16 bytes |\n| tcp6 | IPv6-specific TCP port, big endian integer |\n| udp6 | IPv6-specific UDP port, big endian integer |\n\nAll the fields are optional, except for the `id` field, which is required. If no `tcp6`/`udp6` port are provided, the `tcp`/`udp` ports are used for both IPv4 and IPv6.\n\nThe node record is composed of a `signature`, which is the cryptographic signature of record contents, and a `seq` field, which is the sequence number of the record (a 64-bit unsigned integer).\n#### Encoding\n\nThe record is encoded as an RLP list of `[signature, seq, k, v,...]` with a maximum size of 300 bytes.\nSigned records are encoded as follows:\n```\ncontent = [seq, k, v, ...]\nsignature = sign(content)\nrecord = [signature, seq, k, v, ...]\n```\nIn addition to the RLP encoding, there is a textual representation of the record, which is a base64 encoding of the RLP encoding. It is prefixed with `enr:`.\ni.e. `enr:-IS4QHCYrYZbAKWCBRlAy5zzaDZXJBGkcnh4MHcBFZntXNFrdvJjX04jRzjzCBOonrkTfj499SZuOh8R33Ls8RRcy5wBgmlkgnY0gmlwhH8AAAGJc2VjcDI1NmsxoQPKY0yuDUmstAHYpMa2_oxVtw0RW_QAdpzBQA8yWM0xOIN1ZHCCdl8` which contains the loopback address `127.0.0.1` and the UDP port 30303. The node ID is `a448f24c6d18e575453db13171562b71999873db5b286df957af199ec94617f7`.\n\nDespite of the fact that the ENR is a standard format for p2p connectivity, it is not mandatory to use it in the Ethereum network. The nodes can use any other format to exchange the information about their connectivity.\nThere are two additional formats able to be understand by an Ethereum node: multiaddr and enode.\n\n* The multiaddr was the original one. For example, the multiaddr for a node with a loopback IP listening on TCP port 30303 and node ID `a448f24c6d18e575453db13171562b71999873db5b286df957af199ec94617f7` is `/ip4/127.0.0.1/tcp/30303/a448f24c6d18e575453db13171562b71999873db5b286df957af199ec94617f7`.\n* The enode is a more human-readable format. For example, the enode for the same node is `enode://a448f24c6d18e575453db13171562b71999873db5b286df957af199ec94617f7@127.0.0.1:30303?discport=30301`. It is a URL-like format describing the node ID encoded before de @ sign, the IP address, the TCP port and the UDP port specified as \"discport\".\n\n### RLPx protocol (Transport)\n\nSo far, this article has been referring to the discovering protocol only, but what about the secure information exchange process? Well, RLPx is the TCP-based transport protocol that enables secure peer-to-peer communication in the EL. It handles connection establishment, and message exchange between Ethereum nodes. The name comes from the [RLP serialization format](../EL/RLP.md).\n\nBefore deep diving on the protocol, here it is a summary followed by a digram:\n\n* Secure connection through an encrypted authentication\n* Session establishment\n* Message framing and information exchange\n\n\n![RLPx diagram](../../images/el-architecture/rlpx-communication.png)\n\n#### Secure connection establishment\n\nOnce the nodes are discovered, RLPx establishes a secure connection between them by authenticating each other through cryptographic-based handshake.\nThis process begins by initating an authentication where the initiator node generates an ephemeral key pair using the secp256k1 elliptic curve. This ephemeral key plays a crucial role in establishing perfect forward secrecy for the session. Then the initiator sends an authentication message including the ephemeral public key and a nonce to the recipient, which accepts the connection, decrypts and verify the auth message with the public key exchanged during the communication.\n\nThe recipient sends an acknowledge message back to the initiator, and then sends a first encrypted frame containing a [Hello message](https://github.com/ethereum/devp2p/blob/master/rlpx.md#hello-0x00) which includes the port, their IDs and their client's IDs, and the protocol information. Once the nodes have authenticated each other, they can start with the communication.\n\n#### Session and multiplexing\nOnce the authentication is proven they can interact by creating a secure session first through the following process:\n- RLPx uses **Elliptic Curve Integrated Encryption Scheme ([ECIES](https://cryptobook.nakov.com/asymmetric-key-ciphers/ecies-public-key-encryption))** for secure **handshaking and session establishment**.\n- The cryptosystem consists of:\n - **Elliptic Curve**: secp256k1\n - **Key Derivation Function (KDF)**: NIST SP 800-56 Concatenation KDF\n - **Message Authentication Code (MAC)**: HMAC-SHA-256\n - **Encryption Algorithm**: AES-128-CTR\n\n##### Encryption Process\n\n1. **Initiator generates a random ephemeral key pair**.\n2. Computes **shared secret** using **Elliptic Curve Diffie-Hellman (ECDH)**.\n3. Derives encryption (`kE`) and MAC (`kM`) keys from the **shared secret**.\n4. Encrypts the message using **AES-128-CTR**.\n5. Computes a **MAC** over the encrypted message for integrity.\n6. Sends the encrypted payload.\n\n##### Decryption Process\n\n1. **Recipient extracts the sender’s ephemeral public key**.\n2. Computes the **shared secret** using **ECDH**.\n3. Derives `kE` and `kM`, then verifies the **MAC**.\n4. **Decrypts** the message using **AES-128-CTR**.\n\n\n##### Node Identity\n\n- **Ethereum nodes maintain a persistent secp256k1 key pair** for identity.\n- The **public key** serves as the **Node ID**.\n- The **private key is stored securely** and remains unchanged across sessions.\n\n##### Generated Secrets\n\n| Secret | Description |\n|--------|------------|\n| `static-shared-secret` | `ECDH(node-private-key, remote-node-pubkey)` |\n| `ephemeral-key` | `ECDH(ephemeral-private-key, remote-ephemeral-pubkey)` |\n| `shared-secret` | `keccak256(ephemeral-key || keccak256(nonce || initiator-nonce))` |\n| `aes-secret` | `keccak256(ephemeral-key || shared-secret)` |\n| `mac-secret` | `keccak256(ephemeral-key || aes-secret)` |\n\n##### Static-Shared-Secret vs. Ephemeral-Key\n\n###### Static-Shared-Secret\n\n- Derived using Elliptic Curve Diffie-Hellman (ECDH) between a node’s long-term (static) private key and the peer’s long-term public key.\n- Remains unchanged across multiple sessions with the same peer.\n\nIf an attacker compromises a node’s private key, past and future communications with that peer can be decrypted, making it vulnerable to long-term key exposure.\n\n###### Ephemeral-Key (Forward Secrecy)\n\n- A temporary key pair generated for each handshake, used to derive a fresh session secret.\n- Computed using ECDH between ephemeral private keys exchanged during the handshake.\n\nSince ephemeral keys are discarded after a session ends, even if an attacker later obtains a node’s long-term private key, past communications remain secure. This property is known as forward secrecy\n\n\n##### Message Framing\n\n- **Frames encapsulate encrypted messages** for efficient and secure communication.\n- **Multiplexing** allows multiple protocols to run over a single RLPx connection.\n\n##### Frame Structure\n\n| Field | Description |\n|-------|------------|\n| `header-ciphertext` | AES-encrypted **header** containing frame metadata. |\n| `header-mac` | **MAC** over the header for integrity verification. |\n| `frame-ciphertext` | AES-encrypted **message data**. |\n| `frame-mac` | **MAC** over the encrypted message data. |\n\n##### MAC Calculation\n\n- Uses **two keccak256 MAC states** (one for **ingress**, one for **egress**).\n- The MAC state is updated as frames are sent or received.\n- Ensures **message integrity** and prevents **tampering**.\n\n\n##### Capability Messaging\n\n- **Capabilities** define the supported protocols on a given connection.\n- **Multiplexing** enables concurrent usage of multiple capabilities.\n\n##### Message Structure\n\n| Field | Description |\n|-------|------------|\n| `msg-id` | Unique identifier for the message type. |\n| `msg-data` | **RLP-encoded** message payload. |\n| `frame-size` | **Compressed size** of `msg-data`. |\n\n\n#### P2P Capability Messages\n\n- The **\"p2p\" capability** is **mandatory** and used for initial negotiation.\n\n#### Core Messages\n\n| Message | ID | Function |\n|---------|----|----------|\n| `Hello` | `0x00` | Announces supported capabilities. |\n| `Disconnect` | `0x01` | Initiates a graceful disconnection. |\n| `Ping` | `0x02` | Checks if the peer is alive. |\n| `Pong` | `0x03` | Responds to a `Ping`. |\n\n#### Disconnect Reasons\n\n| Code | Reason |\n|------|--------|\n| `0x00` | Requested disconnect. |\n| `0x02` | Protocol violation. |\n| `0x03` | Useless peer. |\n| `0x05` | Already connected. |\n| `0x06` | Incompatible protocol version. |\n| `0x09` | Unexpected identity. |\n\n\n\n\n### Application-Level Subprotocols \n\n- **RLPx supports multiple application-level subprotocols** that enable specialized communication between Ethereum nodes.\n- These subprotocols are **built on top of the RLPx transport layer** and are used for data exchange, state synchronization, and light client support.\n\n#### Common Ethereum Subprotocols \n\n| **Subprotocol** | **Purpose** |\n|---------------|------------|\n| **Ethereum Wire Protocol (`eth`)** | Handles **blockchain data exchange**, including block propagation and transaction relaying. |\n| **Ethereum Snapshot Protocol (`snap`)** | Used for **state synchronization**, allowing nodes to download portions of the state trie. |\n| **Light Ethereum Subprotocol (`les`)** | Supports **light clients**, enabling them to request data from full nodes without storing the full state. |\n| **Portal Network (`portal`)** | A decentralized **state, block, and transaction retrieval network** for lightweight clients. |\n\n\n### Further Reading\n* [Geth devp2p docs](https://geth.ethereum.org/docs/tools/devp2p)\n* [Ethereum devp2p GitHub](https://github.com/ethereum/devp2p)\n* [Ethereum networking layer](https://ethereum.org/en/developers/docs/networking-layer/)\n* [Ethereum Addresses](https://ethereum.org/en/developers/docs/networking-layer/network-addresses/)\n* Alchemy (2022). [How are Ethereum transactions propagated (broadcast)?](https://www.alchemy.com/overviews/transaction-propagation)\n* Andrew S. Tanenbaum, Nick Feamster, David J. Wetherall (2021). *Computer Networks*. 6th edition. Pearson. London.\n* Kevin Leffew (2019). \"Kademlia usage in the Ethereum protocol\". [*A brief overview of Kademlia, and its use in various decentralized platforms*](https://medium.com/coinmonks/a-brief-overview-of-kademlia-and-its-use-in-various-decentralized-platforms-da08a7f72b8f). Medium.\n" }, { "path": "docs/wiki/EL/el-architecture.md", "content": "# Client Architecture\n\n## Overview\n\nBeyond execution layer's fundamental role of transaction execution, the execution layer client undertakes several critical responsibilities. These include verification of the blockchain data and storing its local copy, facilitating network communication through gossip protocols with other execution layer clients, maintaining a transaction pool, and fulfilling the consensus layer's requirements that drive its functionality. This multifaceted operation ensures the robustness and integrity of the Ethereum network.\n\nThe client's architecture is built around a variety of specific standards, each of which plays a unique role in the overall functionality. The execution engine is located at the top, driving the execution layer, which in turn is driven by the consensus layer. The execution layer runs on top of DevP2P, the networking layer, which is initialized by providing legitimate boot nodes that provide an initial access point into the network. When we call one of the engine API methods, such as fork choice updated, we can download blocks from peers by subscribing to topics like our preferred mode of sync.\n\n\n\nThe diagram illustrates a simplified representation of the design, excluding several components.\n\n**EVM**\n\nEthereum is centered around a virtualized central processing unit (CPU). Computers have their own central processing units (CPUs) at a hardware level, which can be of many types such as x86, ARM, RISC-V, or others. These varied processor architectures have unique instruction sets that enable them to perform tasks such as arithmetic, logic, and data manipulation, allowing the computer to function as a general-purpose computing machine. Therefore, when executing a program written in the hardware-level instruction set, the outcome may vary depending on the specific hardware on which it is executed. Thus In computer science, we address this problem by virtualizing instruction sets through the creation of virtual machines, such as the JVM (Java Virtual Machine). These virtual machines ensure consistent results regardless of the underlying hardware. The EVM is a virtualized execution engine designed for ethereum programs. It ensures consistent results regardless of the hardware it runs on and facilitates consensus among all Ethereum clients regarding computation outcomes.\n\nIn addition, Ethereum incorporates a sandwich complexity model as part of its design philosophy. This implies that the outer layers should be uncomplicated, while all the intricacy should be concentrated in the middle layers. In this context, the EVM's code can be seen as the outermost layer, while a high-level language like Solidity may be considered as the top layer. In between, there is a complicated compiler that translates the solidity code into the EVM's bytecode.\n\n**State**\n\nEthereum is a general purpose computational system that operates as a state machine, meaning it may transition between several states depending on the inputs it receives. In addition, Ethereum differs significantly from other blockchains like Bitcoin in that it maintains a global state, whereas Bitcoin only keeps global unspent transaction outputs (UTXOs). The term \"state\" refers to the comprehensive collection of data, data structures (such as Merkle-Patricia Tries), and databases that store various information. This includes addresses, balances, code and data for contracts, as well as the current state and network state.\n\n**Transactions**\n\nThe EVM produces data and modifies the state of the Ethereum network through a process called state transition. This state transition is triggered by transactions, which are processed within the EVM. If a transaction is deemed legitimate, it results in a state change of the Ethereum network.\n\n**DevP2P**\n\nThe interface for communicating with other execution layer clients. Transactions are initially stored in the mempool, which serves as a repository for all incoming transactions, and are disseminated by execution layer clients to other execution layer clients in the network using peer-to-peer communication. Every recipient of the transaction sent over the network confirms its validity before broadcasting it to the network.\n\n**JSON-RPC API**\n\nWhen utilizing a wallet or a DApp, our communication with the execution layer is conducted over a standardized JSON-RPC API. This enables us to externally query the Ethereum state or dispatch a transaction to it, signed by the wallet, which is subsequently validated by the execution layer client and disseminated around the network.\n\n**Engine API**\n\nThe **Engine API** lives in the **Execution Layer** and is used exclusively for internal communication between the **Consensus Layer** and the **Execution Layer (EL)**. The engine exposes two major classes of endpoints to the consensus layer: **fork choice updated** and **new payload** suffixed by the three versions they are exposed as (V1-V3).\n\n1. **New Payload (V1/V2/V3):** \n Handles payload validation and insertion. When the CL receives a new beacon block, it extracts the execution payload and calls `engine_newPayload` on the EL. The EL validates the payload by:\n - Checking that the parent block hash in the payload header exists and matches the expected parent in the local chain.\n - Verifying any additional execution commitments (e.g. post-Cancun data).\n - Executing transactions and updating the state.\n \n The response includes a status:\n - **VALID:** Fully executed and correct.\n - **INVALID:** Payload or an ancestor fails validation.\n - **SYNCING:** EL is still catching up (e.g. missing blocks).\n - **ACCEPTED:** Basic checks pass but full execution is pending (common in shallow-state clients).\n\n2. **Fork Choice Updated (V1/V2/V3):** \n Manages state synchronization and triggers block building. The CL sends a fork choice update (with head, safe, and finalized block hashes) and may include payload attributes if it is selected to propose a block. The EL will:\n - Updates its canonical head.\n - Initiates payload building if payload attributes are provided.\n - Returns a response with a status and, if building, a `payloadId`. The status indicates the EL's current ability to process the fork choice update and (if applicable) begin building a block.\n\nPossible status returned to the CL:\n- **VALID:** The fork choice update was processed successfully, and the EL's view of the chain is up to date.\n- **INVALID:** The provided fork choice references an invalid block or chain segment.\n- **SYNCING:** The EL is still catching up (e.g., missing blocks or state required to evaluate the fork choice).\n- **ACCEPTED:** The fork choice update is accepted provisionally, but full validation is pending. This may occur when the EL has shallow state or incomplete history for non-canonical forks.\n\n**Sync**\n\nIn order to accurately process transactions on Ethereum, it is imperative that we reach a consensus on the global status of the network, rather than solely relying on our local perspective. The global state synchronization of the execution layer client is triggered by the fork choice rule governed by the LMD-GHOST algorithm in the consensus layer. It is then relayed to the execution layer through the fork choice updated endpoint of the engine API. Syncing entails two possible processes: downloading remote blocks from peers and validating them in the EVM. The status responses (VALID, INVALID, SYNCING, ACCEPTED) indicate the EL's current level of synchronization.\n\n### Exchange of Capabilities\n\nBefore regular operation begins, the CL and EL perform a capability exchange via the `engine_exchangeCapabilities` method. This step negotiates the supported Engine API method versions between the clients, ensuring that both parties operate using a common protocol version (e.g., V1, V2, V3). This exchange is critical to ensure compatibility and to enable new features while maintaining backward compatibility.\n\n**Happy Path Flow – Node Startup and Validator Operation:**\n\n1. **Node Startup:** \n - The CL calls `engine_exchangeCapabilities` to share a list of supported Engine API methods and versions with the EL.\n - The EL responds with its own list of supported methods.\n - Next, the CL sends an initial `engine_forkchoiceUpdated` call (with no payload attributes) to inform the EL of the current fork choice.\n - If the EL is still catching up, it returns a status of SYNCING. Once caught up, it responds with VALID.\n\n2. **Validator Operation:** \n - In every slot, the CL sends an `engine_forkchoiceUpdated` call to update the EL's state.\n - When the validator is assigned to propose a block, the CL includes payload attributes in the fork choice update to trigger block building.\n - The EL returns a payload status along with a `payloadId` that the CL later uses with `engine_getPayload` to retrieve the built execution payload.\n - Separately, when the validator receives a beacon block from the network (proposed by another validator), the CL extracts the execution payload and calls `engine_newPayload` on the EL to validate the payload.\n\n## Components of the Architecture\n\n### Engine\n\nThe execution layer client acts as an _execution engine_ and exposes the Engine API, an authenticated endpoint, which connects to the consensus layer client. The engine is also referred to as the external consensus engine by the execution layer clients. The execution layer client can be only be driven by a single consensus layer, but a consensus layer client implementations can connect to multiple execution layer clients for redundancy. The Engine API uses the JSON-RPC interface over HTTP and requires authentication via a [JWT](https://jwt.io/introduction) token. Additionally the Engine JSON-RPC is not exposed to anyone besides the consensus layer. However, it's important to note that the JWT is primarily used for authenticating the Payload, i.e. sender is the consensus layer client, it does not encrypt the traffic.\n\n This design enforces a clear separation of responsibilities: the CL handles consensus and fork choice, while the EL validates and executes transactions.\n\n#### Routines\n\n##### Payload validation\n\nPayload is validated with respect to the block header and execution environment rule sets:\n\n\n\nWith the merge, the function of the execution layer has been altered within the Ethereum network. Previously, it was tasked with the responsibility of managing the consensus of the blockchain, ensuring the correct order of blocks, as well as handling reorganizations. However, after the merge, these tasks have been delegated to the consensus layer, resulting in a significant simplification of the execution layer. Now, we can conceptualize the execution layer as primarily carrying out the state transition function.\n\nIn order to gain a better understanding of the aforementioned concept, it is beneficial to examine the perspective of the consensus layer in relation to the execution layer. The consensus specification defines the _process execution payload_ in the deneb beacon chain specs, which is carried out by the beacon chain while undergoing several verifications required to validate a block and advance the consensus layer. The execution layer here is represented by the `execution_engine` function, which serves as a means of communication between the consensus layer and the execution layer and has a lot of varied complexities to it.\n\nDuring _process execution payload_ , we begin by conducting several high-level checks, including verifying the accuracy of the parent hash and validating the timestamp. Additionally, we perform various lightweight verifications. Subsequently, we transmit the payload to the execution layer, where it undergoes block verification. The notify payload function, is the lowest level function that serves as the interface between the consensus layer and the execution engine. It contains only the function's signature, without any implementation details. Its sole purpose is to transmit the execution payload to the execution engine, which acts as the client for the execution layer. The execution engine then carries out the actual state transition function, which involves verifying the accuracy of block headers and ensuring that transactions are correctly applied to the state. The execution engine will ultimately return a boolean value indicating whether the state transition was successful or not. From the standpoint of the consensus layer, this is simply the validation of blocks.\n\nThis is a simplified description of the block level state transition function (stf) in go. The stf is a crucial component of the block validation and insertion pipeline. Although the example is specific to Geth, it represents the functioning of the stf in other clients as well. It is worth mentioning that the state transition function is rarely referred to by its name in the code of different clients, save for the EELS python spec client. This is because its real operations are divided across many components of the client's architecture.\n\n```go\nfunc stf(parent types.Block, block types.Block, state state.StateDB) (state.StateDB, error) { //1\n if err := core.VerifyHeaders(parent, block); err != nil { //2\n // header error detected\n return nil, err\n }\n for _, tx := range block.Transactions() { //3\n res, err := vm.Run(block.header(), tx, state)\n if err != nil {\n // transaction invalid, block is invalid\n return nil, err\n }\n state = res\n }\n return state, nil\n}\n```\n\n1. State transition function's parameters and return values\n - In this context, we examine both the parent block and the current block in order to validate certain transition logic from the parent block to the current block.\n - We take the state DB in as an argument, which contains all the state data related to the parent block. This represents the most recent valid state.\n - We return the state DB representing the updated state after the state transition\n - if the state transition fails we don't update the state DB and return the error\n2. In the state transition functions procedure we first verify the headers\n - As an illustration of the failure of header verification, let us consider the gas limit field, which is also of historical significance. Currently, the gas limit stands at around 30 million. It's important to note that the gas limit is not fixed within the execution layer. Block producers have the capacity to modify the gas limit using a technique that allows them to increase or decrease it by 1/1024th of the gas limit of the preceding block. Therefore, if you raise the gas limit from 30 million to 40 million within a single block, the header verification will fail because it exceeds the threshold of 30 million plus one-thousandth of 30 million.\n - Additional instances of header verification failure can arise when the block numbers are not in sequential order. Typically, the beacon chain is responsible for detecting such discrepancies, although there are instances where it is detected at this stage as well. Failures may also arise when the 1559 base fee is not accurately updated according to the comparison between the last gas used and the gas limit.\n3. Once the header verification is completed, we consider the environment in the header as the environment in which the transactions should be executed and we apply the transactions. We iterate over the transactions in the block and execute each transaction in the EVM.\n - The block headers are passed to the EVM in order to provide the necessary context for processing the transaction. This context includes instructions such as coinbase, gas limit, and timestamp, which are required for proper execution.\n - Additionally we pass in the transaction and the state\n - In the event of a failed execution, we simply return the error, indicating an invalid transaction within the block and thereby rendering the block invalid. Within the execution layer, the presence of anything erroneous in a block renders the entire block invalid, as it contaminates the block as a whole.\n - Once we confirm the validity of the transactions, we proceed to update our state with the result . The state now represent the accumulated state that has all the transaction in the new block applied to it.\n\nFrom the standpoint of beacon chains, the state transition function mentioned above is encompassed by the invocation of the \"new payload\" function.\n\n```go\nfunc newPayload(execPayload engine.ExecutionPayload) bool {\n if _, err := stf(..); err != nil {\n return false\n }\n return true\n}\n```\n\nThe beacon chain invokes the new payload function and transfers the execution payload as an argument. On the execution layer, we invoke the state transition function using the information from the execution payload. If the state transition function does not produce an error, we return true. Otherwise, we return false to indicate that the block is invalid.\n\n##### Geth\n\n###### Transaction Execution in Geth\nGeth, like other Ethereum execution clients, processes transactions by verifying signatures, checking nonces, deducting gas fees, and updating the state. Transactions first enter the mempool, where they wait to be included in a block. Once picked up, Geth executes them, modifying account balances, contract storage, and other state data.\n\n🔗[ Transaction Execution Specs Code](https://github.com/ethereum/execution-specs/blob/0f9e4345b60d36c23fffaa69f70cf9cdb975f4ba/src/ethereum/shanghai/fork.py#L542)\n\n###### Block Processing & State Updates\nEvery new block contains multiple transactions that Geth processes in order. Once all transactions are executed, the final state is committed, and a state root hash is stored to ensure consistency. This process follows a defined set of rules to maintain network integrity.\n\n🔗 [State Transition Code](https://github.com/ethereum/execution-specs/blob/0f9e4345b60d36c23fffaa69f70cf9cdb975f4ba/src/ethereum/shanghai/fork.py#L145)\n\n###### Networking & Peer-to-Peer Communication\nEthereum nodes communicate using DevP2P, a protocol that allows execution clients to exchange transactions and blocks. When a new transaction is sent, it propagates across the network through peer-to-peer connections, ensuring all nodes remain in sync. Each recipient verifies the transaction before forwarding it, preventing spam and invalid state transitions.\n\n🔗[DevP2P Specification]( https://github.com/ethereum/devp2p/blob/master/caps/eth.md)\n\n###### EVM Execution\nAt its core, Geth runs the Ethereum Virtual Machine (EVM), which processes smart contract logic. Every transaction that interacts with a contract is executed inside the EVM, ensuring consistency and determinism across all nodes.\n\n🔗 [EVM Code in Geth]( https://github.com/ethereum/go-ethereum/blob/master/core/vm/evm.go#L90)\n\n##### State Sync\n\nAll execution clients require an up‑to-date world state to validate and build blocks. To bootstrap a new node's current state, clients leverage Ethereum’s DevP2P subprotocols: `eth/*` (wire protocol) for block headers, bodies, and receipts, and `snap/1` for creating state snapshots. Using these sub-protocols, clients can choose between two sync strategies, **full sync** or **snap sync**. The difference between the snap synced node and a full block-by-block synced node is that a snap synced node started from an initial checkpoint that was more recent than the genesis block.\n\nLet's look at how the flows of both **full sync** and **snap sync** work.\n\n### Full Sync\nFull Sync trades absolute trustlessness for time and resources. The client replays every block and transaction from genesis to tip, rebuilding the state trie step by step:\n1. Use `GetBlockHeaders` over the `eth/*` protocol to download every block header since genesis.\n2. Use `GetBlockBodies` to retrieve every block’s transactions and uncles.\n3. Sequentially execute each transaction in EVM order, updating the local trie at each block.\n4. Confirm that the local state trie’s root matches the tip’s root. Every state transition has been verified.\n\nThis method guarantees maximal security but can take days on mainnet and consumes significant CPU, disk, and network resources. Full sync is a naive default strategy because it starts from genesis and takes longer over time as block height continually grows. Additionally, full sync from genesis will no longer be supported after [EIP-4444](https://eips.ethereum.org/EIPS/eip-4444) is fully implemented. Syncing after EIP-4444 will be **checkpoint syncs** instead, meaning that syncing will start from a weak subjectivity checkpoint instead of from genesis.\n\n### Snap Sync\nSnap Sync reconstructs the pivot block's state by fetching only the trie leaves (accounts and storage slots) plus Merkle proofs, then separately downloading any needed contract bytecode, and finally rebuilding the tries locally:\n1. Choose a recently finalized block as your pivot block.\n2. Over eth/*, request that block’s header via `GetBlockHeaders` to learn its stateRoot. \n3. Fetch headers up to the pivot via `eth/*`, so you know which state root to target.\n4. Download the leaves of the pivot block's world state trie and account storage trie in chunks.\n - **Accounts**: uses `GetAccountRange` to pull contiguous world state trie leaf values.\n - **Storage**: uses `GetStorageRanges` to pull consecutive storage slot leaf nodes for each account.\n5. Send `GetByteCodes` for every code hash found in the account bodies to get back the contract code for that account\n6. Locally insert every fetched leaf into a fresh snapshot DB, verifying each batch against the pivot block’s stateRoot via Merkle range proofs.\n> Note: In practice, clients store these fetched leaves in a snapshot-specific database format, which differs from the Merkle trie used during normal execution. This format is optimized for range queries and quick reconstruction. The full MPT structure is created and validated during the healing phase.\n\n### Healing Phase\nAfter step 6, we have a snapshot of the pivot block’s state stored in a flat snapshot database. However, since the chain continues to progress, data can be stale, incomplete, or inconsistent. Therefore, a healing phase is required. During healing, the client walks the snapshot DB and verifies that the state data is complete and consistent with the pivot block’s stateRoot. Any missing trie nodes, storage slots, or contract bytecode are fetched using targeted snap requests. Healing ensures that the final state is complete, consistent, and can be fully reconstructed into a valid MPT.\n\nAt this point, we have a snapshot of the pivot block's state, so we apply the transactions of blocks following the pivot on the downloaded state to get to the tip of the chain.\n\nSnap Sync reduces mainnet bootstrap times from days to hours. Its trade‑off is that it's hardware intensive for the healing phase to be able to outpace trie changes from new blocks being produced.\n\nBoth **full sync** and **snap sync** finishes when blockchain data is verified and clients catches up with the tip of the chain which enables building the latest state. \n\n##### Payload building\n\nMore details in [block production](/wiki/EL/block-production.md)\n\n#### Methods\n\n##### New payload\n\nValidates the payload that was built earlier by the payload building routine.\n\n\n\n##### Fork choice updated\n\nProof-of-stake LMD-GHOST fork choice rule & payload building routine instantiation.\n\n\n\n### Internal Consensus engines\n\nThe execution layer has its own consensus engine to work with its own copy of the beacon chain. The execution layer consensus engine is known as ethone and has about half the functionality of the full fledged consensus engine of the consensus layer.\n\n| Function | Beacon (Proof-of-stake) | Clique (Proof-of-authority) | Ethash (Proof-of-work) |\n| ----------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------- |\n| **Author**: Eth address of the block minter | If the header is classified as a Proof of Stake (PoS) header, with a header difficulty set to 0, we will retrieve the header's coinbase. Otherwise, we will forward the header to the beacon's ethone engine (either clique or ethash) for further processing. | Obtains the account address that created the block. The process of recovering the public key from the header's extraData is performed by ecrerecover. | |\n| **Verify Header(s)**: Processes a batch of headers and validates them according to the rules of the current consensus engine. : | Split the headers based on [Terminal Total difficulty](https://eips.ethereum.org/EIPS/eip-3675#definitions) into pre and post TTD batches . Verify the pre batches with the ethone engine and the post by beacon's verify header. | | |\n| | Here we perform block header verification similar to the one in the [execution layer Specs](wiki/EL/el-specs?id=block-header-validation) wiki page and covered below in the client code table. | We verify the time of the header is not greater than system time. | |\n| | | If it is a checkpoint block (1'st slot of an epoch), then ensure it has no beneficiary. | |\n| | | The header nonce can take on two values: 0x00..0, which indicates a vote to add a signer, or 0xff..f, which indicates a vote to drop a signer. However, at checkpoints, we can only vote to drop a signer. | |\n| | | The extraData length mush account for vanity + signature. At checkpoints, the extraData contains the signer list + signature. | |\n| | | Header gas checks. | |\n| | | Retrieve the snapshot | |\n| | | On checkpoint blocks verify the signers in the snapshot against the extraData | |\n| | | Invoke the verify Seal function to determine whether all the criteria for the signature included in the header have been satisfied. The recovery process involves extracting information from the header and the list of recent signers in the Clique object. We then verify whether the signer is included in the snapshot. | | |\n| **Verify Uncles** | If the Header is a Proof-of-stake header, check that the length of uncles is 0. If the header is not Proof-of-stake, the process of verifying uncles is done via the ethone engine. | In Clique no uncles should be present | |\n| **Prepare**: Initializes the consensus fields of a block's header. | If TTD is reached we set the header's difficulty to beacon's difficulty of 0, else we call ethone's prepare | Create the voting snapshot by supplying the parent hash and number.During the reverse iteration process, we start from the block number and proceed backwards. We stop the iteration if we reach the genesis block, if we are using a light client that doesn't store parent blocks, if we reach an epoch by traversing backwards, or if the headers traversed exceed the soft Finality value (indicating that the segment is considered immutable). At the checkpoint where we stop the iteration, we create a snapshot. | |\n| | | If we are at the end of an epoch, we will go through the addresses in the proposals field of the snap object and choose one randomly as the coinbase. If the proposal is authorized, we will cast an auth-vote; otherwise, we will cast a drop vote. | |\n| | | Set the header difficulty based on the signer's turn (2 if the signer is in turn and 1 if not) | |\n| | | Verify that the extraData contains all the necessary elements, including extraVanity and a list of signers if the block occurs at the end of the epoch. This is added to the Header's extraData field. | |\n| **Finalize**: After making changes to the state, the state database may be updated, but this action does not involve the assembly of the block. | If the header is not a Proof-of-stake header, we execute the finalize function of ethone. Otherwise, we loop through the withdrawals in the block, converting their amounts from wei to gwei. We then modify the state by adding the converted amount to the address associated with the current withdrawal. | Clique has no post-transaction consensus rules, no block rewards in proof of authority | |\n| **FinalizeAndAssemble**: Finalizes and assemble the final block | If the header is not a Proof-of-stake header, we invoke ethone's FinalizeAndAssemble. If there are no withdrawals and the block is after the Shanghai fork, we include an empty withdrawals object. Next, we invoke the finalize function to calculate the state root. We then assign this value to the root property of the header object. Finally, we construct a new block by combining the header, transactions, uncles, receipts, and withdrawals. | Verify that there are no withdrawals, invoke the finalize function, calculate the state root of our stateDB, and assign it to the the Header . Construct a new block using the header, transactions, and receipts. | |\n| **Seal**: Generates a sealing request for a block and pushes the request into the given channel | If the header is not a Proof-of-stake header, we invoke ethone's seal. Otherwise, we take no action and return nil. The verification of the seal is performed by the consensus layer. | Make sure that the block is not the initial block, obtain the snapshot, and confirm that we have the authority to sign and are not included in the list of recent signers. Coordinate the timing of our respective turns, apply the sign function to  sign, and transmit the securely sealed block through the designated channel. | |\n| **SealHash**: Hash of the block prior to sealing | | | |\n| **CalcDifficulty**: Difficulty adjustment algorithm, returns the difficulty of the new block | | | |\n\n#### Client code\n\n| | EELS(cancun) | Geth | Reth | Erigon | Nethermind | Besu |\n| ----------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---- | ---- | ------ | ---------- | ---- |\n| $V(H) \\equiv H_{gasUsed} \\leq H_{gasLimit}$ | [validate_header](https://github.com/ethereum/execution-specs/blob/9fc7925c80ff2f3949e1cc340a4a0d36fcd4161c/src/ethereum/cancun/fork.py#L294) | | | | | |\n| $H_{gasLimit} < P(H)_{H_{gasLimit'}} + floor(\\frac{P(H)_{H_{gasLimit'}}}{1024} ) $ | validate_header -> calculate_base_fee_per_gas -> [ensure](https://github.com/ethereum/execution-specs/blob/9fc7925c80ff2f3949e1cc340a4a0d36fcd4161c/src/ethereum/cancun/fork.py#L256) | | | | | |\n| $H_{gasLimit} > P(H)_{H_{gasLimit'}} - floor(\\frac{P(H)_{H_{gasLimit'}}}{1024} ) $ | '' | | | | | |\n| $H_{gasLimit} > 5000$ | calculate_base_fee_per_gas -> [check_gas_limit](https://github.com/ethereum/execution-specs/blob/9fc7925c80ff2f3949e1cc340a4a0d36fcd4161c/src/ethereum/cancun/fork.py#L1132) | | | | | |\n| $H_{timeStamp} > PH)_{H_{timeStamp'}} $ | validate_header-> [ensure](https://github.com/ethereum/execution-specs/blob/9fc7925c80ff2f3949e1cc340a4a0d36fcd4161c/src/ethereum/cancun/fork.py#L323) | | | | | |\n| $H_{numberOfAncestors} = PH)_{H_{numberOfAncestors'}} + 1 )$ | validate_header-> [ensure](https://github.com/ethereum/execution-specs/blob/9fc7925c80ff2f3949e1cc340a4a0d36fcd4161c/src/ethereum/cancun/fork.py#L324) | | | | | |\n| $length(H_{extraData}) \\leq 32_{bytes} $ | validate_header-> [ensure](https://github.com/ethereum/execution-specs/blob/9fc7925c80ff2f3949e1cc340a4a0d36fcd4161c/src/ethereum/cancun/fork.py#L325) | | | | | |\n| $H_{baseFeePerGas} = F(H) $ | | | | | | |\n| $H_{parentHash} = KEC(RLP( P(H)_H )) $ | validate_header-> [ensure](https://github.com/ethereum/execution-specs/blob/9fc7925c80ff2f3949e1cc340a4a0d36fcd4161c/src/ethereum/cancun/fork.py#L332) | | | | | |\n| $H_{ommersHash} = KEC(RLP(())) $ | validate_header-> [ensure](https://github.com/ethereum/execution-specs/blob/9fc7925c80ff2f3949e1cc340a4a0d36fcd4161c/src/ethereum/cancun/fork.py#L329) | | | | | |\n| $H_{difficulty} = 0 $ | validate_header-> [ensure](https://github.com/ethereum/execution-specs/blob/9fc7925c80ff2f3949e1cc340a4a0d36fcd4161c/src/ethereum/cancun/fork.py#L327) | | | | | |\n| $H_{nonce} = 0x0000000000000000 $ | validate_header-> [ensure](https://github.com/ethereum/execution-specs/blob/9fc7925c80ff2f3949e1cc340a4a0d36fcd4161c/src/ethereum/cancun/fork.py#L328) | | | | | |\n| $H_{prevRandao} = PREVRANDAO() $ (this is stale , beacon chain provides this now) | | | | | | |\n| $H_{withdrawalHash} \\neq nil $ | | | | | | |\n| $H_{blobGasUsed} \\neq nil $ | | | | | | |\n| $H_{blobGasUsed} \\leq MaxBlobGasPerBlock_{=786432} $ | | | | | | |\n| $H_{blobGasUsed} \\% GasPerBlob_{=2^{17}} = 0 $ | | | | | | |\n| $H_{excessBlobGas} = CalcExcessBlobGas(P(H)_H) $ | [ensure](https://github.com/ethereum/execution-specs/blob/9fc7925c80ff2f3949e1cc340a4a0d36fcd4161c/src/ethereum/cancun/fork.py#L187) | | | | | |\n\n### Downloader\n\n### Transaction Pools\n\nIn Ethereum two primary types of transaction pools are recognized:\n\n1. **Legacy Pools**: Managed by execution client, these pools employ price-sorted heaps or priority queues to organize transactions based on their price. Specifically, transactions are arranged using two heaps: one prioritizes the effective tip for the upcoming block, and the other focuses on the gas fee cap. During periods of saturation, the larger of these two heaps is selected for the eviction of transactions, optimizing the pool's efficiency and responsiveness. [urgent and floating heaps](https://github.com/ethereum/go-ethereum/blob/064f37d6f67a012eea0bf8d410346fb1684004b4/core/txpool/legacypool/list.go#L525)\n\n2. **Blob Pools**: Unlike legacy pools, blob pools maintain a priority heap for transaction eviction but incorporate distinct mechanisms for operation. Notably, the implementation of blob pools is well-documented, with an extensive comments section available for review [here](https://github.com/ethereum/go-ethereum/blob/064f37d6f67a012eea0bf8d410346fb1684004b4/core/txpool/blobpool/blobpool.go#L132). A key feature of blob pools is the use of logarithmic functions in their eviction queues.\n\nNote that these examples are using go-ethereum, specific naming and implementation details might differ in various clients while main principles stays the same. \n\n### EVM\n\n[Wiki - EVM](/wiki/EL/evm.md)\nTODO: Move relevant code from specs into EVM\n\n### DevP2P\n\n[Wiki - DevP2P](/wiki/EL/devp2p.md)\n\n### Data structures\n\nMore details in the page on [EL data structures](/wiki/EL/data-structures.md).\n\n### Storage and database backends\n\nBlockchain and state data processed by execution client need to be stored in the disk. These are necessary to validate new blocks, verify history and to serve peers in the network. Client stores historical data, also called the ancient database, which include previous blocks. Another database of trie structure contains the current state and small number of recent states. In practice, clients keep various databases for different data categories. Each client can implement a different backend to handle this data, e.g. leveldb, pebble, mdbx.\n\n**Leveldb**\n\nLevelDB is one of the database implementations used by clients, providing a generic ordered key–value interface and had no knowledge of Ethereum-specific structures.\n\nLevelDB is an embedded key–value database based on a log-structured merge tree design. Writes are first appended to a write-ahead log for crash recovery and inserted into an in-memory memtable. When the memtable is full, it is flushed to disk as an immutable sorted string table. On disk, these tables are organized into multiple levels and periodically merged through background compaction. This design favors high sequential write throughput but results in write amplification and variable latency when data is frequently updated.\n\nExecution clients mostly switched away from this specific db implementation to more modern reimplementations with active support or more experimental designs with improved performance. \n\n**Pebble**\n\nPebble is used by some execution clients as a replacement for LevelDB, fulfilling the same role as the primary embedded key–value store for blockchain data, execution state, and indices. Geth have chosen pebble as an alternative and now default backend because LevelDB stopped being maintained. It provides same set of features with certain advantages as its development continues. \n\n\nCompared to LevelDB, Pebble retains the LSM-tree architecture but improves it for write-heavy, latency-sensitive workloads typical of Ethereum execution. It supports multiple active memtables to reduce write stalls, exposes detailed SSTable and compaction metadata, and provides significantly more control over compaction behavior. These improvements allow clients to better manage write amplification and achieve more predictable performance under frequent state updates. \nPebble also offers stronger batch semantics and snapshot support, enabling execution clients to better align database operations with block execution and concurrent RPC reads.\n\nhttps://github.com/cockroachdb/pebble\n\n\n**MDBX**.\n\nRead more about its [features](https://github.com/erthink/libmdbx#features). Additionally, boltdb has a page on comparisons with other databases such as leveldb, [here](https://github.com/etcd-io/bbolt#comparison-with-other-databases). The comparative points mentioned on bolt are applicable to mdbx. \n\n### Resources and References\n\n- [Engine Api Spec](https://github.com/ethereum/execution-apis/blob/main/src/engine/paris.md#payload-validation) • [archived](https://web.archive.org/web/20250318111700/https://github.com/ethereum/execution-apis/blob/main/src/engine/paris.md#payload-validation)\n- [Engine API: A Visual Guide](https://hackmd.io/@danielrachi/engine_api) • [archived](https://web.archive.org/web/20241006232802/https://hackmd.io/@danielrachi/engine_api)\n- [Engine API | Mikhail | Lecture 21](https://youtu.be/fR7LBXAMH7g)\n- [\"Snapping Snap Sync: Practical Attacks on Go Ethereum Synchronising Nodes\" (ETH Zurich)](https://appliedcrypto.ethz.ch/content/dam/ethz/special-interest/infk/inst-infsec/appliedcrypto/research/TavernaPaterson-SnappingSnapSync.pdf)\n- [Geth Docs – Sync Modes](https://geth.ethereum.org/docs/fundamentals/sync-modes?utm_source=chatgpt.com) • [archived](https://web.archive.org/web/20240505050000/https://geth.ethereum.org/docs/fundamentals/sync-modes)\n- [YouTube – \"How to Sync an Ethereum Node with Snap Sync\"](https://www.youtube.com/watch?v=fk50UbUgkMM)\n- [Ethereum.org – Execution Layer Sync Modes](https://ethereum.org/en/developers/docs/nodes-and-clients/#execution-layer-sync-modes) • [archived](https://web.archive.org/web/20240507022042/https://ethereum.org/en/developers/docs/nodes-and-clients/#execution-layer-sync-modes)\n" }, { "path": "docs/wiki/EL/el-clients.md", "content": "# Execution Client\n\n> **Execution clients**, formerly known as *eth1 clients*, are implementing Ethereum [execution layer](https://github.com/ethereum/execution-specs) tasked with processing and broadcasting transactions and managing the state.\nThey receive transactions via p2p, run the computations for each transaction using the [Ethereum Virtual Machine](https://ethereum.org/en/developers/docs/evm/) to update the state and ensure that the rules of the protocol are followed. \nExecution clients can be configured as full nodes which holds the state, historical blockchain including receipts, or as an archive node which retains also all historical states. \n\n## Overview Table\n\nCurrent execution clients used in production are:\n\n| Client | Language | Developer | Status |\n|-------------|----------|-------------------|------------|\n| [Besu](https://github.com/hyperledger/besu) | Java | Hyperledger | Production |\n| [Erigon](https://github.com/ledgerwatch/erigon) | Go | Ledgerwatch | Production |\n| [Geth](https://github.com/ethereum/go-ethereum) | Go | Ethereum Foundation | Production |\n| [Nethermind](https://github.com/NethermindEth/nethermind) | C# | Nethermind | Production |\n| [Reth](https://github.com/paradigmxyz/reth) | Rust | Paradigm | Production |\n\nThere are more execution clients that are in active development and haven't reached maturity yet or has been used in the past:\n\n| Client | Language | Developer | Status |\n| --------------------------------------------------------------- | ---------- | ------------------- | ----------- |\n| [Nimbus](https://github.com/status-im/nimbus-eth1) | Nim | Nimbus | Development |\n| [Silkworm](https://github.com/erigontech/silkworm) | C++ | Erigon | Development |\n| [JS Client](https://github.com/ethereumjs/ethereumjs-monorepo) | Typescript | Ethereum Foundation | Development |\n| [ethrex](https://github.com/lambdaclass/ethrex) | Rust | LambdaClass | Development |\n| [Akula](https://github.com/akula-bft/akula) | Rust | Akula Developers | Deprecated |\n| [Aleth](https://github.com/ethereum/aleth) | C++ | Aleth Developers | Deprecated |\n| [Mana](https://github.com/mana-ethereum/mana) | Elixir | Mana Developers | Deprecated |\n| [OpenEthereum](https://github.com/openethereum/parity-ethereum) | Rust | Parity | Deprecated |\n| [Trinity](https://github.com/ethereum/trinity) | Python | OpenEthereum | Deprecated |\n\n\n## Distribution\n\nThe overwhelming majority of node operators are currently using Geth as an Execution Client. \nIn the interest of supporting the health of the Execution Layer, [it is recommended to use different clients](https://clientdiversity.org/#why) when running nodes. \n\n## Individual clients\n\nAlthough clients implement the same specification, each client offers different set of features and benefits. They come in different programming languages enabling developers of different backgrounds to contribute. \n\n### Besu\n\nDeveloped by the Consensys/Hyperledger Foundation in Java, Besu (Hyperledger Besu) is distinguished for its enterprise-grade features and compatibility with various Hyperledger projects.\nIt supports both public and private networks, offering robust command-line tools and a JSON-RPC API.\n\nNoteworthy Features:\n- [Private Networks](https://besu.hyperledger.org/private-networks/)\n- [Pruning](https://besu.hyperledger.org/public-networks/how-to/bonsai-limit-trie-logs#prune-command-for-mainnet)\n- [Parallel Transaction Execution](https://besu.hyperledger.org/public-networks/concepts/parallel-transaction-execution)\n\n### Erigon\n\nInitially a fork of Geth introduced as turbo-geth, Erigon focuses on optimizing performance, fast synchronization capabilities, and reducing disk space usage. Erigon introduced a new way of managing MPT database resulting in roughly a 5-times reduction in the archive node disk size.\nErigon's architecture allows it to complete a full archive node sync in under three days with less than 3 TB of data storage, making it ideal for running this kind of node. It also includes its own embedded CL client, enabling it to run independently. \n\nNoteworthy Features:\n- [Supported Networks](https://erigon.gitbook.io/erigon/basic-usage/supported-networks)\n- [Pruning](https://erigon.gitbook.io/erigon/basic-usage/usage/type-of-node#full-node-or-pruned-node)\n- [Caplin CL client](https://erigon.gitbook.io/erigon/advanced-usage/consensus-layer/caplin)\n\n### Geth\n\nAs the original Go implementation of Ethereum, the oldest actively maintained client, Geth (Go-Ethereum) enjoys widespread adoption among developers and users alike.\nIt supports various node types (full, light, archive) and is renowned for its extensive toolset, stability and community support.\nGeth's flexibility in deployment—through package managers, Docker containers, or manual setup—ensures its versatility in diverse blockchain environments.\n\nNoteworthy Features:\n- [Pruning](https://geth.ethereum.org/docs/fundamentals/pruning)\n- [Custom EVM Tracer](https://geth.ethereum.org/docs/developers/evm-tracing/custom-tracer)\n- [Monitoring Dashboards](https://geth.ethereum.org/docs/monitoring/dashboards)\n\n### Nethermind\nWritten in C# .NET, Nethermind is designed for stability and integration with existing tech infrastructures.\nIt offers optimized virtual machine performance, comprehensive analytics support and plugin system.\nNethermind is suitable for both private Ethereum networks and decentralized application (dApp) development, emphasizing data integrity and performance scalability.\n\nNoteworthy Features:\n- [Private Networks](https://docs.nethermind.io/fundamentals/private-networks)\n- [Performance tuning](https://docs.nethermind.io/fundamentals/performance-tuning)\n- [Prometheus and Grafana](https://docs.nethermind.io/monitoring/metrics/grafana-and-prometheus)\n\n### Reth\n\nReth (Rust Ethereum) is a modular and efficient Ethereum client designed for user-friendliness and high performance. Inspired by Erigon design, it's built around novel archive node approach that enables fast sync with small disk footprint.\nIt emphasizes community-driven development and is suitable for robust production environments.\n\nNoteworthy Features:\n- [Revm](https://bluealloy.github.io/revm/)\n- [Monitoring](https://reth.rs/run/observability.html)\n\n### Nimbus\n\nNimbus focuses on efficiency and security as an ultra-lightweight Ethereum execution layer client. Originally working on Nimbus CL client, a new team spin out to develop an execution client in Nim. \nIt minimizes resource consumption while supporting Ethereum's execution layer functionalities and integrating with Fluffy (a Portal Network light client).\nNimbus offers enhanced memory savings and state synchronization mechanisms, ideal for resource-constrained environments.\n\n### Silkworm\nSilkworm is a C++ implementation of the Ethereum Execution Layer protocol, aiming to be the fastest Ethereum client.\nIt integrates the libmdbx database engine and emphasizes scalability, modularity and performance optimizations within the Erigon project (known as Erigon++).\n\n### JS Client\nThe JavaScript client is developed by EF JS team as a part of the [EthereumJS monorepo](https://github.com/ethereumjs/ethereumjs-monorepo). It's experimental and serves mostly for testing but as it's designed to be JavaScript-centric, it's suitable for web and Node.js environments.\n\n## Additional resources\n\n- [ETH Docker](https://eth-docker.net/)\n- [Ethernodes](https://ethernodes.org/)\n- [Client Diversity](https://clientdiversity.org/)\n- [Run the majority client at your own peril!](https://dankradfeist.de/ethereum/2022/03/24/)\n" }, { "path": "docs/wiki/EL/el-data-structures-summary.md", "content": "# Ethereum Execution Layer Data Structures\n\n# Block Header\n\n| name | description| EIP / Fork |\n|------- | ------- | ------- |\n| parent_hash | Hash of the previous block | |\n| ommers_hash | Hash of the ommers (a.k.a. uncles) list | |\n| beneficiary | Address of the miner or validator who receives block reward | |\n| state_root | Root hash of the world state trie after all txs are executed | |\n| transactions_root | Root hash of the transaction trie for this block | |\n| receipts_root | Root hash of the receipt trie for this block | |\n| logs_bloom | Bloom filter summarizing all logs from receipts in this block | |\n| difficulty | PoW: difficulty of the block. PoS: Unused. | |\n| number | Block number (height in the chain) | |\n| gas_limit | Maximum amount of gas allowed in this block | |\n| gas_used | Total gas used by all transactions in this block | |\n| timestamp | Unix timestamp for when the block was proposed | |\n| extra_data | Arbitrary 32-byte field for additional data (e.g. miner ID) | |\n| prev_randao | POW, was called `mix_hash` and used in nonce verification. PoS: random seed for validators | [EIP-4399](https://eips.ethereum.org/EIPS/eip-4399) / Paris |\n| nonce | PoW: solution for the mining puzzle. PoS: unused | |\n| base_fee_per_gas | Minimum base fee per gas | [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) / London |\n| withdrawals_root | Root of the withdrawals list trie | [EIP-4895](https://eips.ethereum.org/EIPS/eip-4895) / Shanghai |\n| base_fee_per_blob_gas | Minimum base fee per gas. | [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) / Dencun |\n| blob_gas_used | Total blob gas used in the block. | [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) / Dencun |\n| excess_blob_gas | Rolling counter of unused blob gas. | [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) / Dencun |\n| parent_beacon_block_root | SSZ root of the parent beacon block. | [EIP-4788](https://eips.ethereum.org/EIPS/eip-4788) / Dencun |\n| request_root | Root hash of EL-generated cross-layer requests. | [EIP-7685](https://eips.ethereum.org/EIPS/eip-7685) / Pectra | \n\n# Block Body\n\n| name | description| EIP/Fork |\n|------- | ------- | ------- |\n| transactions[] | The list of transactions executed in the block, in order. There can be different types of transactions | |\n| ommers[] | In PoS: empty. In PoW: List of ommers (uncles) | |\n| withdrawals[] | List of ETH withdrawals for validators. | [EIP-4895](https://eips.ethereum.org/EIPS/eip-4895) / Shanghai |\n| requests[] | List of cross-layer requests generated by execution. | [EIP-7685](https://eips.ethereum.org/EIPS/eip-7685) / Pectra |\n\n# State Trie\nTrie rooted in the block header's `state_root`.\nEach leaf node is encoded as `keccak(address1) -> RLP(nonce, balance, storage_root, code_hash)`\n\n| name | description|\n|------- | ------- |\n| nonce | Number of transactions sent (EOA) or created (contract) |\n| balance | Eth balance of the account in wei |\n| storage_root | Root of the account's storage trie |\n| code_hash | keccak256 hash of the account's code for contracts. Empty hash or delegation indicator for EOAs |\n\n# Receipts Trie\nTrie rooted in the block header's `receipts_root`\n\nThe receipts contain the fields below:\n| name | description| EIP / Fork |\n|------- | ------- | ------- |\n| type | Receipt type byte prefix. | [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) / Berlin | \n| status | Indicates the transaction status. 1 = success, 0 = failure. Pre-Byzantium was called `state_root`. | [EIP-658](https://eips.ethereum.org/EIPS/eip-658) / Byzantium |\n| cumulative_gas_used | Total gas used up to and including this tx in the block | |\n| logs_bloom | 256-byte bloom filter summarizing all logs from this tx. | |\n| logs[] | List of event logs emitted during execution | |\n\nEach item in `logs[]` field contains the following items:\n| name | description|\n|------- | ------- |\n| address | Address of the contract that emitted the log |\n| topics[] | Array of indexed topics (includes event signatures) |\n| data | ABI-encoded non-indexed event data | \n\n# Withdrawals Trie\nTrie rooted in the block header's `withdrawals_root`\n\nThe fields of withdrawal are:\n| name | description|\n|------- | ------- |\n| index | A monotonically increasing index |\n| validator_index | Index of the validator making the withdrawal |\n| address | Address to receive the withdrawal |\n| amount | Amount of gwei |\n\n# Transaction Trie\nTrie rooted in the block header's `transactions_root`. Transactions can be of various types.\n\n## Legacy Transaction (type 0x00)\n| name | description | EIP/Fork |\n|------- | ------- | ------- |\n| nonce | Number of txs sent by the sender prior to this. | |\n| gas_price | Legacy pricing model: gas price per unit. | |\n| gas_limit | Max gas this tx is allowed to consume. | |\n| to | Recipient address, or empty for contract creation | |\n| value | Amount of Eth to transfer in wei |\n| data | Calldata for contract interaction or init code for creation |\n| chain_id | Id of the chain | [EIP-155](https://eips.ethereum.org/EIPS/eip-155) / Spurious Dragon |\n| v, r, s | Signature components (used to recover sender address) | | \n\n## Access List Transaction (type 0x01)\nFields same as type 0, but `access_list` added.\nEncoded as `RLP(chain_id, nonce, gas_price, gas_limit, to, value, data, access_list, v, r, s)`\n\n| name | description| EIP/Fork |\n|------- | ------- | ------- |\n| access_list | list of addresses/storage keys to be accessed. | [EIP-2930](https://eips.ethereum.org/EIPS/eip-2930) / Berlin |\n\n## Dynamic-Fee Transaction (type 0x02) \nEncoded as `RLP(chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, to, value, data, access_list, v, r, s)` which extends Type 1 transactions by replacing `gas_price` with new fields.\n\n| name | description| EIP/Fork |\n|------- | ------- | ------- |\n| max_priority_fee | Tip for the validator to incentivize inclusion above other transactions. | [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) / London |\n| max_fee_per_gas | Maximum fee willing to pay per unit of gas. | [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) / London |\n\n## Blob-Carrying Transaction (type 0x03) \nEncoded as `RLP(chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, to, value, data, access_list, max_fee_per_blob_gas, blob_versioned_hashes, v, r, s)`\n\nSame as type 2 transactions, except with new blob-related field.\n\n| name | description| EIP/Fork |\n|------- | ------- | ------- |\n| max_fee_per_blob_gas | Maximum fee willing to pay per blob gas unit. | [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) / Dencun |\n| blob_versioned_hashes | List of hashes for each blob. | [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) / Dencun |\n\n## Set Code Transaction for EOAs (type 0x04)\nExtends type 3 transactions with a new `authorization_list` with fields below.\n\n| name | description| EIP/Fork |\n|------- | ------- | ------- |\n| chain_id | Id of the chain | [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702) / Prague |\n| address | Address of smart contract to delegate to | [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702) / Prague |\n| nonce | Number of txs sent by the sender prior to this. | [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702) / Prague |\n| y_parity, r, s | Cryptographic signature elements | [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702) / Prague |\n\n" }, { "path": "docs/wiki/EL/el-specs.md", "content": "# Execution Layer Specification\n\nThe execution layer was originally specified in the yellow paper as it encompassed the whole Ethereum. The most up to date specification is [EELS python spec](https://ethereum.github.io/execution-specs/).\n\n> - [Yellow Paper, paris version 705168a – 2024-03-04](https://ethereum.github.io/yellowpaper/paper.pdf) (note: This is outdated does not take into account post merge updates)\n> - [Python Execution Layer specification](https://ethereum.github.io/execution-specs/)\n> - EIPs [Look at Readme of the repo](https://github.com/ethereum/execution-specs)\n\nThis page provides an overview of EL specification, its architecture and context for the pyspec.\n\n## State transition function\n\nThe Execution Layer, from the EELS perspective, focuses exclusively on executing the state transition function (STF). This role addresses two primary questions[¹]:\n\n- Is it possible to append the block to the end of the blockchain?\n- How does the state change as a result?\n\nSimplified Overview:\n\n\nThe image above represents the block level state transition function in the yellow-paper.\n\n$$\n\\begin{equation}\n\\sigma_{t+1} \\equiv \\Pi(\\sigma_t, B)\n\\qquad (2) \\nonumber\n\\end{equation}\n$$\n\nIn the equation, each symbol represents a specific concept related to the blockchain state transition:\n\n- $\\sigma_{t+1}$ represents the **state of the blockchain** after applying the current block, often referred to as the \"new state.\"\n- $\\Pi$ denotes the [block level state transition function](https://github.com/ethereum/execution-specs/blob/0f9e4345b60d36c23fffaa69f70cf9cdb975f4ba/src/ethereum/shanghai/fork.py#L145), which is responsible for transitioning the blockchain from one state to the next by applying the transactions contained in the current block.\n- $\\sigma_t$ represents the state of the **[blockchain](https://github.com/ethereum/execution-specs/blob/0f9e4345b60d36c23fffaa69f70cf9cdb975f4ba/src/ethereum/shanghai/fork.py#L73)** before adding the current block, also known as the \"previous state.\"\n\n- $B$ symbolizes the **[current block](https://github.com/ethereum/execution-specs/blob/0f9e4345b60d36c23fffaa69f70cf9cdb975f4ba/src/ethereum/shanghai/fork_types.py#L217)** that is being sent to the execution layer for processing.\n\nFurthermore, it's crucial to understand that $\\sigma$ should not be confused with the `State` class defined in the Python specification. Rather than being stored in a specific location, the system's state is dynamically derived through the application of the state collapse function. This highlights the conceptual separation between the mathematical model of blockchain state transitions and the practical implementation details within software specifications.\n\n\n\nThe id's in the above image as represented in the yellow paper (paris version) :\n\n| Id. | equation no. | yellow paper | comments |\n| ----- | ------------ | --------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| 1 | [7](https://ethereum.github.io/yellowpaper/paper.pdf#page=4) | $$TRIE(L_I^*(\\sigma[a]_s)) \\equiv \\sigma[a]_s $$ | This gives the root of the account storage Trie ,$\\sigma[a]_s $ on the right, after mapping each node with the function $L_I((k,v)) \\equiv (KEC(k), RLP(v))$ . The equation on the left is referring to mapping over underlying key and values of the account storage $\\sigma[a]_s $ these are two different objects the left $\\sigma[a]_s $ and the right $\\sigma[a]_s $ which represents the root hash |\n| 2 | | [page 4](https://ethereum.github.io/yellowpaper/paper.pdf#page=4), paragraph 2 | The account state $\\sigma[a] $ is described in the yellow paper |\n| 3 | [10](https://ethereum.github.io/yellowpaper/paper.pdf#page=4) | $$L_s(\\sigma) \\equiv \\{p(a) : \\sigma[a] \\neq \\empty \\} $$ | This is the world state collapse function , applied to all accounts considered not empty: |\n| 4 & 5 | [39](https://ethereum.github.io/yellowpaper/paper.pdf#page=7) | $$TRIE(L_s(\\sigma)) = P(B_H)_{H_{stateRoot}} $$ | The equation defines the Parent block's state root header as the root given by the TRIE function where $P(B_H)$ is the Parent Block |\n| 6. | [35b](https://ethereum.github.io/yellowpaper/paper.pdf#page=7) | $$H_{stateRoot} \\equiv TRIE(L_s(\\Pi(\\sigma, B))) $$ | this gives us the state root of the current block |\n\nThe specified procedure for the state transition function in the code documentation includes the following steps:\n\n1. **Retrieve the Header**: Obtain the header of the most recent block added to the chain, referred to as the parent block.\n2. **Excess Blob Gas Validation**: Calculate excess blob gas from the parent header and ensure it matches the current blocks header parameter excess_blob_gas\n3. **Header Validation**: Compare and validate the current block's header against that of the parent block.\n4. **Ommers Field Check**: Verify that the ommers field in the current block is empty. Note: \"ommers\" is the gender-neutral term that replaces the previously used term \"uncles.\"\n5. **Block Execution**: Execute the transactions within the block, which yields the following outputs:\n - **Gas Used**: The total gas consumed by executing all transactions in the block.\n - **Trie Roots**: The roots of the tries for all transactions and receipts contained in the block.\n - **Logs Bloom**: A bloom filter of logs from all transactions within the block.\n - **State**: The state, as specified in the python execution specs, after executing all transactions.\n6. **Header Parameters Verification**: Confirm that the parameters returned from executing the block are present in the block header. This includes comparing the state's root with the `state_root` field in the block header.\n7. **Block Addition**: If all checks are successful, append the block to the blockchain.\n8. **Pruning Old Blocks**: Remove blocks that are older than the most recent 255 blocks from the blockchain.\n9. **Error Handling**: If any validation checks fail, raise an \"Invalid Block\" error. Otherwise, return None.\n\n## Block Header Validation\n\nThe process of block header validation, rigorously defined within the yellow paper and the python spec, verifies the block integrity based on Ethereum protocol rules, e.g. hash verification, gas usage, timestamp accuracy, etc. This validation ensures every block complies with Ethereum protocol defined in the specification and implemented in the client. During sync and appending blocks, validation is an integral function of a blockchain by independently verifying current and historical data.\n\nThe [validity](https://github.com/ethereum/execution-specs/blob/0f9e4345b60d36c23fffaa69f70cf9cdb975f4ba/src/ethereum/shanghai/fork.py#L269) of a block header, as specified in the Yellow Paper, employs a series of criteria to ensure each block adheres to Ethereum's protocol requirements. The parent block, denoted as $P(H)$, is necessary to validate the current block header $H$ . The key conditions for validity include:\n\n$$V(H) \\equiv H_{gasUsed} \\leq H_{gasLimit} \\qquad (57a)$$\n$$\\land$$\n$$H_{gasLimit} < P(H)_{H_{gasLimit'}} + floor(\\frac{P(H)_{H_{gasLimit'}}}{1024} ) \\qquad (57b)$$\n$$\\land $$\n$$H_{gasLimit} > P(H)_{H_{gasLimit'}} - floor(\\frac{P(H)_{H_{gasLimit'}}}{1024} ) \\qquad (57c)$$\n$$\\land$$\n$$H_{gasLimit} > 5000\\qquad (57d)$$\n$$\\land $$\n$$H_{timeStamp} > P(H)_{H_{timeStamp'}} \\qquad (57e)$$\n$$\\land$$\n$$H_{numberOfAncestors} = P(H)_{H_{numberOfAncestors'}} + 1 \\qquad (57f)$$\n$$\\land$$\n$$length(H_{extraData}) \\leq 32_{bytes} \\qquad (57g)$$\n$$\\land$$\n$$H_{baseFeePerGas} = F(H) \\qquad (57h)$$\n$$\\land$$\n$$H_{parentHash} = KEC(RLP( P(H)_H )) \\qquad (57i) $$\n$$\\land$$\n$$H_{ommersHash} = KEC(RLP(())) \\qquad (57j)$$\n$$\\land$$\n$$H_{difficulty} = 0\\qquad (57k)$$\n$$\\land $$\n$$H_{nonce} = 0x0000000000000000 \\qquad (57l)$$\n$$\\land$$\n$$H_{withdrawalHash} \\neq nil \\qquad (57n)$$\n$$\\land$$\n$$H_{blobGasUsed} \\neq nil \\qquad (57o)$$\n$$\\land$$\n$$H_{blobGasUsed} \\leq MaxBlobGasPerBlock_{=786432} \\qquad (57p)$$\n$$\\land $$\n$$H_{blobGasUsed} \\% GasPerBlob_{=2^{17}} = 0 \\qquad (57q)$$\n$$\\land $$\n$$H_{excessBlobGas} = CalcExcessBlobGas(P(H)_H) \\qquad (57r)$$\n$$\\land $$\n$$\nCalcExcessBlobGas(P(H)_H) \\equiv \\nonumber \\\\\n\\begin{aligned}\n&\\begin{cases}\n0, \\qquad \\text{if} \\space P(H)_{blobGasUsed} < TargetBlobGasPerBlock \\\\\nP(H)_{blobGasUsed} - TargetBlobGasPerBlock\n\\end{cases}\n\\quad (57s)\n\\end{aligned}\n$$\n$$\\land $$\n$$\n\\begin{aligned}\nP(H)_{blobGasUsed} \\equiv P(H)_{H_{excessBlobGas}} + P(H)_{H_{blobGasUsed}} \\\\\nTargetBlobGasPerBlock = 393216\n\\end{aligned}\n\\quad (57t)\n$$\n\n- **Gas Usage**: The gas used by a block $H_{gasUsed}$ must not exceed the gas limit $H_{gasLimit'}$, ensuring transactions fit within the block's capacity (57a).\n- **Gas Limit Constraints**: The gas limit of a block must remain within specified bounds relative to the parent block's gas limit ${P(H)_{H_{gasLimit'}}}$ , allowing for gradual changes rather than abrupt adjustments (57b, 57c).\n- **Minimum Gas Limit**: A minimum gas limit of 5000 ensures a basic level of transaction processing capacity (57d).\n- **Timestamp Verification**: Each block's timestamp $H_{timeStamp}$ must be greater than that of its parent $P(H)_{H_{timeStamp'}}$, ensuring chronological order (57e).\n- **Ancestry and Extra Data**: The block maintains a lineage through the $H_{numberOfAncestors'}$ field and limits the $H_{extraData}$ size to 32 bytes (57f, 57g).\n- **Economic Model Compliance**: The base fee per gas $H_{baseFeePerGas}$ is calculated according to the rules established in EIP-1559, reflecting the network's current demand for transaction processing (57h). This along with a,b,c,d & h defines part of the Economic model\n\n### Header validation and the Ethereum economic model\n\nThe Ethereum economic model, as outlined in [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559), introduces a series of mechanisms aimed at enhancing network efficiency and stability:\n\n- **Targeted Gas Limit for Reduced Volatility**: By setting the gas target at half the maximum gas limit, Ethereum aims to diminish the volatility that full blocks can cause, ensuring a more predictable transaction processing environment.\n- **Prevention of Unnecessary Delays**: This model seeks to eliminate undue delays for users by optimizing transaction processing times, thus improving the overall user experience on the network.\n- **Stabilizing Block Reward Issuance**: The issuance of block rewards contributes to the system's enhanced stability, providing a more predictable economic landscape for participants.\n- **Predictable Base Fee Adjustments**: EIP-1559 introduces a mechanism for predictable base fee changes, a feature particularly beneficial for wallets. This predictability aids in accurately estimating transaction costs ahead of time, streamlining the transaction creation process.\n- **Base Fee Burn and Priority Fee**: Under this model, miners are entitled to keep the priority fee as an incentive, while the base fee is burned, effectively removing it from circulation. This approach serves as a countermeasure to Ethereum's inflation, promoting a healthier economic environment by reducing the overall supply over time.\n\nAdditional checks ensure legacy compatibility and security, such as the ommer (uncle block) hash and difficulty fields being set to predefined values, reflecting the transition from Proof of Work to Proof of Stake (57j-57l).\n\nThese criteria form part of the Ethereum economic model, particularly influenced by EIP-1559, which introduces a dynamic base fee mechanism. This mechanism aims to optimize network usage and fee predictability, enhancing user experience and economic stability. Additionally, [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) introduced a new type of transaction, blob transactions, that augments the economic model from EIP-1559.\n\nLets explore this in more depth and try to gain a better understanding on whats going on with these equations that's not easily visible in either the python spec or the yellow paper.\n\nLets start with expanding 57h, specified in the yellow paper as:\n\n$$\n\\begin{equation}\nF(H) \\equiv\n\\begin{cases}\n10^9 & \\text{if } H_{number} = F_{London} \\nonumber \\\\\nP(H)_{H_{baseFeePerGas}} & \\text{if } P(H)_{H_{gasUsed}} = \\tau \\nonumber \\\\\nP(H)_{H_{baseFeePerGas}} - \\nu & \\text{if } P(H)_{H_{gasUsed}} < \\tau \\nonumber \\\\\nP(H)_{H_{baseFeePerGas}} + \\nu & \\text{if } P(H)_{H_{gasUsed}} > \\tau\n\\end{cases}\n\\qquad (45)\n\\end{equation}\n$$\n\n$$\n\\tau \\equiv \\frac {P(H)_{H_{gasLimit}}} {\\rho} \\qquad (46)\n$$\n\n$$\n\\rho \\equiv 2 \\qquad (47)\n$$\n\n$$\n\\nu^* \\equiv\n\\begin{cases}\n\\frac{P(H)_{H_{baseFeePerGas}} \\times (\\tau - P(H)_{H_{gasUsed}})}{\\tau} & \\text{if } P(H)_{H_{gasUsed}} < \\tau \\\\\n\\frac{P(H)_{H_{baseFeePerGas}} \\times (P(H)_{H_{gasUsed}} - \\tau)}{\\tau} & \\text{if } P(H)_{H_{gasUsed}} > \\tau\n\\end{cases} \\qquad (48)\n$$\n\n$$\n\\nu \\equiv\n\\begin{cases}\n\\left\\lfloor \\frac{\\nu^*}{\\xi} \\right\\rfloor & \\text{if } P(H)_{H_{gasUsed}} < \\tau \\\\\n\\max\\left(\\left\\lfloor \\frac{\\nu^*}{\\xi} \\right\\rfloor, 1\\right) & \\text{if } P(H)_{H_{gasUsed}} > \\tau\n\\end{cases} \\qquad (49)\n$$\n\n$$\n\\xi \\equiv 8 \\qquad (50)\n$$\n\n| Symbol | What it represents | value | comments |\n| --------------- | ------------------------------------------ | -------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- |\n| $F(H) $ | Base Fee per Gas | | Paid be the sender as part of the Total Fee , The Base Fee is finally burnt by Execution Layer and taken out of the system |\n| $\\nu $ | Magnitude increase or decrease in base fee | | Proportional to the difference between Parent block's gas consumption and gas target |\n| $\\tau $ | Gas target | $\\frac {P(H)_{H_{gasLimit}}} {\\rho}_{= 2}$ | Aimed at reducing volatility, the gas target is set at half the gas limit to moderate transaction throughput per block. |\n| $\\rho $ | Elasticity multiplier | 2 | aids in adjusting the gas target to maintain network responsiveness, capacity and price predictability. |\n| $\\xi $ | Base fee max denominator | 8 | it controls the maximum rate of change in the base fee, ensuring gradual adjustments. |\n\nFurthermore the yellow paper has some crucial definitions on the types of these objects that will be used in reasoning about these equations :\n\nFirst it provides us with unbounded block limits, i.e. These limits can be extended infinitely\n\n$$\nH_{\\text{gasUsed}} , H_{\\text{gasLimit}}, H_{\\text{baseFeePerGas}} \\in \\mathbb{N} \\qquad (41)\n$$\n\nThen it provides us with the types for the transaction parameter , These are bounded by a max value of 2^256 or approx 10^77, that's the max these numbers can go to\n\n$$T_{\\text{maxPriorityFeePerGas}} , T_{\\text{maxFeePerGas}}, T_{\\text{gasLimit}}, T_{\\text{gasPrice}} \\in\\mathbb{N}_{256}$$\n\n#### Additional Insights: The Significance of Natural Numbers\n\nThe Ethereum protocol designates block-level parameters—such as gas used ($H_{gasUsed}$), gas limit ($H_{gasLimit}$), and base fee per gas ($H_{baseFeePerGas}$)—as natural numbers $\\mathbb{N}$ This decision is far from arbitrary; it embeds a layer of intuitive logic into the blockchain's foundational economics.\n\n- Natural Numbers and Blockchain Logic\n\nNatural numbers, starting from 0 and extending infinitely, offer a straightforward framework for understanding and manipulating these parameters. Unlike real numbers, which include an uncountable infinity between any two points, natural numbers allow for exact, discrete steps—making them ideal for blockchain transactions where precision is paramount. This property simplifies the reasoning about functions that manipulate these parameters, facilitating precise calculations and predictions about transaction costs and network capacity.\n\n- Simplicity and Precision\n\nConsider the simplicity of incrementing: each natural number can be thought of as a sum of (0 + 1 + 1 + ... + 1), providing a clear path for incrementation or decrementation within smart contracts or transaction processing. This atomic nature of natural numbers, with 0 and Successor(+ 1) foundational building blocks, enables the construction of robust and provable logic within the Ethereum blockchain, in other words natural numbers lead to easier proofs.\n\n- Contrasting with Real Numbers (decimals)\n\nIn contrast to the infinite divisibility of real numbers, the discrete nature of natural numbers within Ethereum's economic model ensures that operations remain within computable bounds. This distinction is crucial for maintaining network efficiency and security, avoiding the computational complexity and potential vulnerabilities associated with handling real numbers.\n\n**Transaction Parameters and Bounded Natural Numbers**\n\nFurthermore, Ethereum specifies transaction parameters, such as the maximum priority fee per gas and maximum fee per gas , within a bounded subset of natural numbers $\\mathbb{N}_{256}$. This bounding, capped at $2^{256}$ or approximately $10^{77}$, strikes a balance between allowing a vast range of values for transaction processing and ensuring that these values remain within secure, manageable limits.\n\n#### Dynamics of Gas Price Block to Block\n\nLet's delve into the dynamics of the gas price calculation function by exploring its impact across a spectrum of gas usage scenarios, ranging from the minimum possible (5,000 units) to the set gas limit. Our focus is to understand how this function performs within the scope of a single block.\n\nWe aim to analyze the 'calculate base fee per gas' function, which is integral to understanding Ethereum's gas pricing mechanism. The following R code snippet illustrates the implementation of this function:\n\n\n\nObservations from the plot:\n\n- The function exhibits a step-like linear progression, with the widest variance at the midpoint. This reflects the gas target, set at half the gas limit (15,000 units in this case).\n- The maximum upward change in the base fee is approximately 12.5%, observed at the extreme right of the plot. This represents the maximum possible increase when the base fee starts at a hundred.\n- The maximum downward change in the base fee is approximately 10%, observed at the extreme left of the plot. This represents the maximum possible decrease when the base fee starts at a hundred.\n- A precise hit on the gas target results in a 1% increase in the base fee. Exceeding the target slightly (e.g., between 15,000 and 17,000 units of gas used) still results in only a 1% increase, illustrating the function's designed elasticity around the target.\n\n#### Extended Simulation: Long-term Effects on Gas Limit and Fee\n\nHaving visualized the immediate impact of the gas price calculation function over a range of gas usage scenarios, let's to consider its effect over an extended period. Specifically, how does this dynamic influence the Ethereum network over tens of thousands of blocks, especially under conditions of maximum demand where each block reaches its gas limit?\n\nThe following plot simulates this scenario over 100,000 blocks, assuming a constant maximum demand, to project the evolution of the gas limit and base fee:\n\n\n\nObservations from the simulation reveal several critical insights:\n\n- Base Fee Sensitivity: The base fee, measured in wei, escalates rapidly, potentially reaching one ether within a mere 200 blocks under continuous maximum demand.\n- Potential to Hit Upper Limits: Under sustained high demand, the base fee could approach its theoretical maximum in under 2,000 blocks.\n- Unbounded Gas Limit Growth: Unlike the base fee, the gas limit itself is not capped, allowing for continuous growth to accommodate increasing network demand.\n- Market Dynamics and Equilibrium: Real-world demand increases, initially reflected in blocks exceeding their gas targets, lead to rising base fees. However, as the gas limit gradually increases, the gas target (half the gas limit) also rises, eventually stabilizing demand against the higher base fee, reaching a new equilibrium.\n\nTo future-proof our analysis by examining the model's underpinnings at a more granular level. Specifically, we focus on the effects of altering the constants central to the model, notably the elasticity multiplier ($\\rho$) and the base fee max change denominator ($\\xi$). These constants are not expected to change within a fork but can be re-specified in future protocol upgrades:\n\nlet's start with $\\xi$ :\n\n\n\nThis is a snapshot between blocks, like our first plot, it represents smallest slice of the potential of the economic model additionally parameterized by $\\xi$ across protocol upgrades\n\nImpact of $\\xi$ on base fee:\n\n- Inflection point & step width variability: The \"kink\" or point of inflection becomes particularly pronounced with variations to $\\xi$, becoming broader as $\\xi$ increases. Thus increasing $\\xi$ results in broader step widths, indicating more gradual fee adjustments. Conversely, decreasing $\\xi$ leads to narrower steps and more volatile fee changes.\n- Sensitivity: The slope of the base fee adjustment curve changes significantly beyond the inflection point. As $\\xi$ values decrease, we observe a sharp increase in the rate of fee adjustments, indicating heightened sensitivity.\n- Linear Trend within Target Range: The central portion of the curve, particularly highlighted by the light green line for the current $\\xi$ value of the Ethereum protocol, showcases a mostly linear trend in fee adjustments as transactions approach or exceed the gas target.\n\nNext, we turn our attention to the elasticity multiplier ($\\rho$), another pivotal constant in Ethereum's economic model that directly influences the flexibility and responsiveness of gas limit adjustments. To understand its impact, we explore a range of values for $\\rho$ from 1 to 6 in conjunction with variations in the base fee max change denominator ($\\xi$).\n\n\n\nImpact of $\\rho$ and $\\xi$ on Base Fee :\n\n- Moment-to-Moment Analysis: Similar to our initial observations, this plot offers a granular view into how adjustments in $\\rho$ and $\\xi$ shape the economic model's behavior on a per-block basis, especially in the context of protocol upgrades.\n- Distinct Influence of $\\rho$: Each subplot represents effect of varying $\\rho$ values. As the elasticity multiplier, $\\rho$ notably shifts the inflection point in the base fee adjustment curve, highlighting its role in tuning the network's responsiveness to transaction volume fluctuations.\n- Interplay Between $\\rho$ and $\\xi$: The elasticity multiplier ($\\rho$) not only moves the inflection point but also modulates the sensitivity of adjustments attributable to changes in the base fee max change denominator ($\\xi$). This interaction underscores the delicate balance Ethereum maintains to ensure network efficiency and stability amidst varying demands.\n\n\n\n#### Dynamics of Blob Gas Price\n\nThe dynamics of the Blob Gas Price are modeled in the following scenarios, starting from zero and increasing the gas used per block by a constant factor of 1000 from one block to the next.\n\n- Figure E: Illustrates the relationship between blob gas and its price. Code to all the figures is in the appendix\n\n\n\n- Figure F: Normalizes the data to highlight the price dynamics relative to gas usage.\n \n\n- The blob gas price remains at 1 when the parent block's gas usage is below the target (~400K, corresponding to approximately 400KB or 3 blobs per block). A maximum of about 800K maps to roughly 800KB or 6 blobs per block.\n- Surpassing the target does not immediately affect the gas price, but excess gas begins to accumulate.\n- Persistent demand increases, causing the accumulated excess gas to surpass a threshold, triggering an exponential increase in the gas price as a regulatory measure.\n- Accumulated excess gas can be cleared in one block if the gas usage of the preceding block falls below the target, resetting the adjustment mechanism.\n\n## Block Execution Process\n\nAfter initial header verification, the block advances to the execution phase([apply_body](https://github.com/ethereum/execution-specs/blob/804a529b4b493a61e586329b440abdaaddef9034/src/ethereum/cancun/fork.py#L437)). Performing header checks early allows the State Transition Function (STF) to potentially return an \"Invalid Payload\" message to the Consensus Layer (CL) without proceeding to the computationally intensive stage of block/transaction execution.\n\n1. **Initialize `blobGasUsed` to 0.** This sets the starting point for gas used by transactions in the block to zero.\n2. **Set `gasAvailable` to $H_{gasLimit}$.** This initializes the gas available for the block's execution to the block's gas limit.\n3. **Initialize additional execution components:** This includes setting up the receipt's trie, withdrawal's trie, and a block logs tuple (which behaves like an immutable list), ensuring the gas available aligns with the block's gas limit.\n4. **Access Beacon Block Roots Contract Code** via the EL constant that specifies the **BEACON ROOTS ADDRESS**:\n - This feature, introduced in Duncan and detailed in [EIP 4788](https://eips.ethereum.org/EIPS/eip-4788), enables the use of beacon chain block roots as cryptographic accumulators for constructing proofs of the Consensus Layer State. This provides a trust-minimized way for the EVM to access consensus layer data, supporting applications such as staking pools, restaking operations, smart contract bridges, and MEV mitigations. [Learn More](https://www.youtube.com/watch?v=GriLSj37RdI) from the spec's creator.\n5. **Construct a System Transaction Message:** With the **System Address** as the caller and **BEACON ROOTS ADDRESS** as the target, include $H_{parentBeaconBlockRoot}$ and the retrieved contract code. This introduces a \"system contract\" in Duncan, a stateful smart contract unlike stateless precompiles, where only the system address can insert data.\n6. **Set up the VM environment and process the message call,** storing $H_{parentBeaconBlockRoot}$ in the contract's storage for later retrieval by transactions providing the slot's timestamp.\n7. **Delete empty accounts** touched in the previous steps to clean up the state.\n8. **Process transactions within the block:**\n - Transactions are decoded and added to the transaction trie for execution.\n - **Execute the [Transaction](/wiki/EL/transaction):** Critical to the block execution process, this involves:\n 1. Recovering the transaction sender's address using the signature components $T_v, T_r, T_s$.\n 2. Verifying intrinsic transaction validity.\n 3. Calculating the effective gas price.\n 4. Initializing the execution environment.\n 5. **Executing the decoded transaction** within the virtual machine, including validation against the current state, gas calculations, and applying state changes upon success.\n9. **Process validator withdrawals** validated by the beacon chain ([EIP-4895](https://eips.ethereum.org/EIPS/eip-4895)):\n - Iterate over each [Withdrawal](https://github.com/ethereum/execution-specs/blob/119208cf1a13d5002074bcee3b8ea4ef096eeb0d/src/ethereum/shanghai/fork_types.py#L178), adding them to the trie.\n - Convert withdrawals from Gwei to Wei and credit the specified addresses.\n - Destroy empty withdrawal accounts to maintain a clean state.\n\n### Environment initialization\n\n$$\nI_{caller} = T_{Sender_{address}}, \\nonumber \\\\\nI_{origin} = T_{Sender_{address}}, \\nonumber \\\\\nI_{blockHashes} = blockHashes_{Last255}, \\nonumber \\\\\nI_{coinbase} = H_{coinbase}, \\nonumber \\\\\nI_{number} = H_{number}, \\nonumber \\\\\nI_{gaslimit} = Header_{gasLimit} - cumulativeGasUsed, \\nonumber \\\\\nI_{baseFeePerGas} = H_{baseFeePerGas}, \\nonumber \\\\\nI_{gasPrice} = effectiveGasPrice, \\nonumber \\\\\nI_{time} = H_{timeStamp}, \\nonumber \\\\\nI_{prevRandao} = H_{prevRandao}, \\nonumber \\\\\nI_{state} = state, \\nonumber \\\\\nI_{chainId} = H_{chainId}, \\nonumber \\\\\nI_{traces} = [], \\nonumber \\\\\nI_{excessBlobGas} = excessBlobGas, \\nonumber \\\\\nI_{blobVersionedHashes} = T_{blobVersionedHashes}, \\nonumber \\\\\n$$\n\n| Variable | Description |\n| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------ |\n| $I_{caller}$ | The address initiating the code execution; typically the sender of the transaction. |\n| $I_{origin}$ | The original sender address of the transaction initiating this execution context. |\n| $I_{blockHashes}$ | A collection of the hashes from the last 255 blocks. |\n| $I_{coinbase}$ | The beneficiary address for block rewards and transaction fees. |\n| $I_{number}$ | The sequential number of the current block within the blockchain. |\n| $I_{gasLimit}$ | The maximum amount of gas available for executing the transaction, accounting for gas already used in the current block. |\n| $I_{baseFeePerGas}$ | The base fee per gas unit, a dynamic parameter that adjusts with block space demand. |\n| $I_{gasPrice}$ | The effective gas price, influenced by current network conditions and transaction urgency. |\n| $I_{time}$ | The timestamp marking when the block was produced, measured in seconds since the Unix epoch. |\n| $I_{prevRandao}$ | The previous RANDAO (randomness) value, contributing to the entropy in block production from the Beacon chain. |\n| $I_{state}$ | The current state, encompassing all account balances, storage, and contract code. |\n| $I_{chainId}$ | Identifier for the blockchain, ensuring transactions are signed for a specific chain. |\n| $I_{traces}$ | A placeholder for execution traces, intended for future use or debugging purposes. |\n| $I_{excessBlobGas}$ | Calculated from the parent block, it represents surplus gas allocated for blob transactions. |\n| $I_{blobVersionedHashes}$ | the ordered list of versioned hashes of blobs that are attached to the current transaction. |\n\n## Gas Accounting\n\n### Intrinsic Gas Calculation\n\nIntrinsic gas represents the minimum gas required for a transaction to begin execution. This cost encompasses the computational resources needed by the EVM and the costs associated with data transfer. The intrinsic gas is subtracted from the transaction's $T_{gasLimit}$ to set up the execution context within the EVM.\n\nUpdated to align with the Shanghai Specification, the intrinsic gas formula, where $T$ stands for Transaction and $G$ for Gas Cost, is as follows:\n\n$$\ng_0 \\equiv\n$$\n\n$$\n\\begin{aligned}\nG_{\\text{initCodeWordCost}} \\times\n&\\begin{cases}\n\\text{length}, & \\text{if length} \\mod 32 = 0 \\\\\n\\text{length} + 32 - (\\text{length} \\mod 32), & \\text{otherwise}\n\\end{cases}\\\\\n&\\qquad\\text{if } \\text{CALLDATA} = T_{\\text{initializationCode}}\n\\end{aligned}\n$$\n\n$$+$$\n\n$$\n\\begin{aligned}\n&\\begin{cases}\n\\sum_{i \\in \\{T_{\\text{inputData}}\\}}\n\\begin{cases}\nG_{\\text{txdatazero}} & \\text{if } i = 0 \\\\\nG_{\\text{txdatanonzero}} & \\text{otherwise}\n\\end{cases}\n\\end{cases}\\\\\n&\\qquad\\text{if } \\text{CALLDATA} = T_{inputData} \\lor T_{initializationCode}\n\\end{aligned}\n$$\n\n$$+$$\n\n$$\n\\{ \\begin{array}{ll}\nG_{\\text{txcreate}} & \\text{if } T_{to} = \\emptyset \\\\\n0 & \\text{otherwise}\n\\end{array}\n$$\n\n$$+$$\n\n$$\nG_{\\text{transaction}}\n$$\n\n$$+$$\n\n$$\n\\sum_{j=0}^{ length(T_{accessList}) - 1} \\left( G_{\\text{accesslistaddress}} + length(T_{accessList}[j]_s) * G_{\\text{accessliststorage}} \\right)\n$$\n\n#### Intrinsic Gas Components:\n\n| Component | Description |\n| ------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| $g_0$ | Represents the total intrinsic gas cost of a transaction, covering initial code execution and data transfer. |\n| $G_{\\text{transaction}}$ | The base cost for every transaction, set at 21000 gas. |\n| $T_{\\text{initializationCode}}$ | When $T_{to} = 0_{\\text{Bytes}}$, CALLDATA is considered as $T_{\\text{initializationCode}}$. Costs are normalized to 32-byte intervals. |\n| $T_{inputData}$ and $T_{initializationCode}$ | Collectively, $T_{inputData}$ and $T_{initializationCode}$ represent the CallData parameter of the transaction. If $T_{to} \\neq 0_{Bytes}$, CALLDATA is treated as the input to the contract's entry point. The gas cost for processing CALLDATA is defined as 16 gas per non-zero byte and 4 gas per zero byte, impacting block size and potentially network delay due to increased processing. This gas cost model was based on a balance of block creation rate, chain growth rate, and network latency, initially optimized for Proof of Work systems. Adapting this model for Proof of Stake remains a research opportunity and area for future optimization. These parameters are defined as an unlimited size byte array, with the initialization cost set at 16 gas for each non-zero byte and 4 gas for each zero byte. More |\n| $G_{\\text{txCreate}}$ | An additional 32000 gas is required for contract creation transactions. |\n| $G_{\\text{accesslistaddress}}, G_{\\text{accessliststorage}}$ | Additional gas costs for each address and storage key specified in the access list, facilitating optimized state access. |\n\n### Effective Gas Price & Priority Fee\n\nThe equations below were modified to include blob transactions ( $T_{type} = 3$ )\n\n$$ p \\equiv effectiveGasPrice \\equiv\n\\begin{aligned}\n&\\begin{cases}\nT_{gasPrice}, & \\text{if} \\space T_{type} = 0 \\lor 1\\\\\npriorityFee + H_{baseFeePerGas} , & \\text{if} \\space T_{type} = 2 \\lor 3\n\\end{cases}\\\\\n\\end{aligned} \\qquad (62)\n$$\n\n$$ f \\equiv priorityFee \\equiv\n\\begin{aligned}\n&\\begin{cases}\nT_{gasPrice} - H_{baseFeePerGas}, & \\text{if} \\space T_{type} = 0 \\lor 1\\\\\nmin(T_{maxPriorityFeePerGas} , T_{maxFeePerGas} - H_{baseFeePerGas}) , & \\text{if} \\space T_{type} = 2 \\lor 3\n\\end{cases}\\\\\n\\end{aligned}\n$$\n\n| | |\n| ----------------- | --------------------------------------------------------------------------------------------------------------------------- |\n| effectiveGasPrice | The amount of wei the Transaction signer will pay per unit Gas consumed during the execution of the transaction |\n| priorityFee | The amount of wei the Transaction's beneficiary will receive per unit Gas consumed during the execution of the transaction |\n\n### Effective Gas Fee\n\n$$effectiveGasFee \\equiv effectiveGasPrice \\times T_{gasLimit} $$\nDeducted as part of the upfront cost\n\n### Total Blob Gas\n\n$$totalBlobGas \\equiv (G_{gasPerBlob = 2^{17}} \\times length(T_{blobVersionedHashes}) ) $$\n\n### Blob Gas Price\n\nThe Blob Gas Price is determined through a formula that adjusts based on the excess blob gas generated in the network. The formula is as follows:\n\n$$\nblobGasPrice \\\\ \\approx \\\\\nfactor_{minBlobBaseFee = 1} \\times e^{numerator_{excessBlobGas} / denominator_{blobGaspriceUpdateFraction = 3338477}}\n$$\n\n- The formula returns 1 for any input under the current maximum blob gas per block (set at 786432) , if excess gas has not accumulated.\n- However it starts increasing when the target is breached over blocks , which causes the Excess Blob Gas Parameter to start accumulating , this triggers the Blob Gas Price to exponentially increase\n- With the target set at approximately half of the maximum blob gas per block (393216), the function starts to show an increase to a value of 2 at ten times the target, after which it rises exponentially.\n\n\n### Blob Gas Fee\n\n$$blobGasFee \\equiv totalBlobGas \\times blobGasPrice $$\n\n### Max Gas Fee\n\n$$\n maxGasFee \\equiv\n\\begin{aligned}\n&\\begin{cases}\nT_{gasLimit} \\times T_{gasPrice} , & \\text{if} \\space T_{type} = 0 \\lor 1\\\\\nT_{gasLimit} \\times T_{maxFeePerGas} , & \\text{if} \\space T_{type} = 2 \\\\\n(T_{gasLimit} \\times T_{maxFeePerGas}) + maxBlobFee , & \\text{if} \\space T_{type} = 3\n\\end{cases}\\\\\n\\end{aligned}\n$$\n\n$$\nmaxBlobFee \\equiv\nT_{maxFeePerBlobGas} \\times totalBlobGas\n$$\n\n### Up-Front Cost\n\n$$\nv_0 \\equiv upfrontCost \\equiv effectiveGasFee + blobGasFee\n$$\n\n## Transaction Execution\n\nThe process of executing a transaction within the Ethereum network is governed by the transaction-level state transition function:\n\n$$\\Upsilon(\\sigma_t, T_{index}) \\qquad (4)$$\n\nUpon invocation of $\\Upsilon$, the system first verifies the intrinsic validity of the transaction. Once validated, the [Ethereum Virtual Machine](/wiki/EL/evm) (EVM) initiates state modifications based on the transaction's directives.\n\n### Transaction Intrinsic Validity\n\nThe intrinsic validity of a transaction is determined through a series of checks:\n\n$$\n\\begin{align}\n(65)\\quad Sender(T) &\\neq EMPTY(\\sigma, account) \\\\ \\land \\nonumber\\\\\n\\sigma[Sender(T)]_{code} &= \\text{KEC}(\\emptyset) \\\\ \\land \\nonumber\\\\\nT_{nonce} &< 2^{64} - 1 \\\\ \\land \\nonumber \\\\\nT_{inputData} &\\leq 2 \\times MaxCodeSize_{=24576}\\\\ \\land \\nonumber \\\\\nT_{nonce} &= \\sigma[Sender(T)]_{nonce} \\\\ \\land \\nonumber \\\\\nintrinsicGas &\\leq T_{gasLimit}\\\\ \\land \\nonumber \\\\\nmaxGasFee + T_{value} &\\leq \\sigma[Sender(T)]_{balance}\\\\ \\land \\nonumber \\\\\nm &\\geq H_{baseFeePerGas}\\\\ \\land \\nonumber \\\\\n\\text{if} \\space T_{type} = 2 \\lor 3 : T_{maxFeePerGas} &\\geq T_{maxPriorityFeePerGas} \\\\ \\land \\nonumber \\\\\nT_{gasLimit} \\leq Header_{gasLimit} \\nonumber \\\\ &− last( \\left[ Block_{receipt} \\right] )_{cumulativeGasUsed} \\\\\n\\end{align}\n$$\n\n$$ \\text{Where, }m \\equiv\n\\begin{aligned} \\\\\n&\\begin{cases}\nT_{gasPrice}, & \\text{if} \\space T_{type} = 0 \\lor 1\\\\\nT_{maxFeePerGas} , & \\text{if} \\space T_{type} = 2 \\lor 3\n\\end{cases}\\\\\n\\end{aligned}\n$$\n\nAnd $EMPTY(\\sigma, account)$ is defined as an account with no code, zero nonce, and zero balance:\n\n$$\n\\begin{align}\nEMPTY(\\sigma, account) \\nonumber \\\\ \\equiv \\nonumber \\\\\n\\sigma[account]_{code} = \\text{KEC}(\\emptyset) \\nonumber \\\\ \\land \\nonumber \\\\\n\\sigma[account]_{nonce} = 0 \\nonumber \\\\ \\land \\nonumber \\\\\n\\sigma[account]_{balance} = 0 \\nonumber \\\\\n\\end{align}\n$$\n\n| | |\n| --- | ---------------------------------------------------------------------------------------------------------------- |\n| 1 | The transaction sender must exist and cannot be an uninitialized account |\n| 2 | The sender cannot be a contract |\n| 3 | Transactions from an account are capped, ensuring a nonce less than $2^{64} - 1$. |\n| 4 | The size of input data or CALLDATA must not exceed twice the maximum code size (24576 bytes). |\n| 5 | The transaction's nonce must match the current nonce of the sender in the state |\n| 6 | The intrinsic gas calculation must not exceed the transaction's gas limit. |\n| 7 | The sender must have sufficient balance to cover the maximum gas fee plus the value being sent. |\n| 8 | Ensures the transaction meets the minimum base fee per gas of the block |\n| 9 | For EIP-1559 transactions, the max fee per gas must be at least as high as the max priority fee per gas |\n| 10 | The transaction's gas limit, plus the gas used by previous transactions in the block, must not exceed the block' |\n\n### $T$ Execution stage 1 : checkpoint state $\\sigma_0$\n\nThe initial stage of transaction execution includes the following steps:\n\n1. **Validate Transaction**: Assess the transaction's validity; if it passes, changes to the state are irrevocably initiated.\n2. **Deduct Intrinsic Gas**: The intrinsic gas amount $g_0$ is subtracted from the transaction's gas limit to establish the gas parameter for message preparation: $gas = T_{gasLimit} - g_0$.\n3. **Increment Sender's Nonce**: Reflect an irrevocable change in the sender's state by incrementing the nonce.\n4. **Deduct Upfront Cost**: The sender's balance is reduced by the upfront cost, another irreversible change to the state.\n\n$$\\sigma_0 \\equiv \\sigma \\space \\text{except:} $$\n$$\\sigma_0[Sender]_{balance} \\equiv \\sigma[Sender]_{balance} - upfrontCost_{\\nu_0} $$\n$$\\sigma_0[Sender]_{nonce} \\equiv \\sigma[Sender]_{nonce} + 1 $$\n\nThis checkpoint state represents the modified state after initial validations and deductions, setting the groundwork for subsequent execution steps.\n\n### $T$ Execution stage 2 : Transaction Normalization and Substate initialization\n\nEVM executions fundamentally require just an environment and a message. Therefore, transactions within a transaction envelope, which categorize transactions by type, are streamlined into four main types. These transactions are then unified into a singular Message Data structure, delineating two main actions: initiating contract creations and executing calls to addresses. Notably, for transactions predating EIP-1559 that lack a base fee, they undergo normalization to integrate the [Gas price](https://github.com/ethereum/go-ethereum/blob/100c0f47debad7924acefd48382bd799b67693cf/core/state_transition.go#L168) during their transformation into the message format. Moreover, the execution path is determined based on the $T_{to}$ parameter:\n\n- if $T_{to} = 0Bytes$ : Proceed with execution of contract creation\n- if $T_{to} = Address$ : Proceed with execution of a call\n\nThis maps to the internal Message type in EELS as :\n\n$$\nmessage(caller, target, gas, value,\\\\ data, code, depth, current Target ,\\\\ codeAddress, shouldTransferValue, isStatic,\\\\ preAccessedAddresses, preAccesedStorageKeys,\\\\ parentEVM)\n$$\n\n| Message Field parameter | Initial Call Value | Initial Creation Value | Execution Environment Forward Mapping |\n| ----------------------- | ----------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------- |\n| caller | Recovered Sender Address | Recovered Sender Address | $I_origin$ or $I_{sender}$ |\n| target | $T_{to}$ is a valid Address | $T_{to} = 0_{bytes}$ | |\n| gas | $T_{gasLimit} - intrinsicCost$ | $T_{gasLimit} - intrinsicCost$ |\n| value | $T_{value}$ | $T_{value}$ | yellow paper: $I_v$ or $I_{value}$ |\n| data | $T_{data}$ | $0_{bytes}$ | yellow paper: $I_d$ or $I_{data}$ |\n| code | $(T_{to})_{code}$ | $T_{data}$ | yellow paper: $I_b$ or $I_{[byteCode]}$ |\n| depth | $0$ | $0$ | yellow paper: $I_e$ or $I_{depth}$ |\n| currentTarget | $T_{to}$ | We compute the contract address by taking the last 20 bytes of $KEC(RLP([Sender_{address}, Sender_{nonce} -1]))$ |\n| codeAddress | $T_{to}$ default except when an alternative accounts code needs execution . e.g. 'CALLCODE' calling a precompile | | yellow paper: $I_a$ or $I_{codeOwnerAddress}$ |\n| shouldTransferValue | default is True, indicates if ETH should be transferred during executing this message | default is True |\n| isStatic | default is False, indicates is State Modifications are allowed (false means state modifications are allowed) | default is False | inversely related to yellow paper: $I_w$ or $I_{permissionToModifyState}$ |\n| accesslistAddress | See below | - |\n| accesslistStorageKeys | - | - |\n| parentEvm | initially None | initially None |\n\n#### Substate initialization\n\nThe initialization of the substate sets the groundwork for transaction execution, defined as follows:\n\n- **Self-Destruct Set**: Initially empty, indicating no contracts are marked for self-destruction.\n- **Log Series**: Starts as an empty tuple, ready to record logs produced during execution.\n- **Touched Accounts**: Also begins empty, listing accounts that become \"touched\" through the transaction.\n- **Refund Balance**: Set to 0, accounting for gas refunds that may accumulate.\n\nDepending on the transaction type, accessed addresses are initialized differently:\n\n- For $T_{type} = 0$, the coinbase address, the caller , the current target and all the pre-compile contract addressees are added to the accessed account substate\n- For $T_{type} = 1, 2, or \\space 3$, the coinbase address , the caller , the current target, all the pre-compiles and those in the access list are added\n\n$$A^* \\equiv (A^{*}_{selfDestructSet} = \\empty, $$\n$$A^{*}_{logSeries} = (), $$\n$$A^{*}_{touchedAccounts} = \\empty, $$\n$$A^{*}_{refundBalance} = 0 , $$\nif $T_{type} = 0$:\n$$A^{*}_{accesedAccountAddresses} = \\{ H_{coinBase},$$\n$$Message_{caller}, Message_{current_target} $$\n$$allPrecompiledContract_{addresses}\\}$$\n$$A^{*}_{accesedStorageKeys} = \\empty $$\nif $T_{type} = 1 \\lor 2 \\lor 3$:\n$$A^{*}_{accesedAccountAddresses} = \\{ H_{coinBase},$$\n$${ \\bigcup_{Entry \\in T_{accessList}} \\{ Entry_{address} \\}},$$\n$$Message_{caller}, Message_{current_target} $$\n$$allPrecompiledContract_{addresses}\\}$$\n$$A^{*}_{accesedStorageKeys}= $$\n$${ \\bigcup_{Entry \\in T_{accessList}} \\{ \\forall i < length(Entry_{storageKeys}), i \\in \\mathbb{N} : (Entry_{address_{20byte}}, Entry_{storageKeys}[i]_{32byte} \\}}$$\n\n`A_{accessedAccountAddresses}` and `A_{accessedStorageKeys}` leverage the mechanism introduced by [Ethereum Access Lists (EIP-2930)](https://eips.ethereum.org/EIPS/eip-2930), detailed further in [this EIP-2930 overview](https://www.rareskills.io/post/eip-2930-optional-access-list-ethereum). This approach creates a distinction in gas costing between addresses and storage keys declared within the transaction's access list (incurring a \"warm\" cost) and those not included (incurring a \"cold\" cost). For comprehensive details on the gas costs associated with cold and warm accesses, please refer to [EIP-2929: Gas cost increases for state access opcodes](https://eips.ethereum.org/EIPS/eip-2929), which adjusts the costs to account for state access operations within the EVM.\n\n$A_{accesedAccountAddresses}$ and $A_{accesedStorageKeys}$ belong to [Ethereum Access lists](https://www.rareskills.io/post/eip-2930-optional-access-list-ethereum) [ EIP ](https://eips.ethereum.org/EIPS/eip-2930) which makes a [cost](https://eips.ethereum.org/EIPS/eip-2929) distinction between the addresses the transaction declares it will call and others. The ones outside the access list have have only a cold cost of account access set at 2600 each time we call the address or 2100 when we access the state. Where as the access list eip specifies that the subsequent calls to the state and account access ,termed \"warm cost\", will incur a gas of 100. [EIP 3651](https://eips.ethereum.org/EIPS/eip-3651) added the coinbase to the list of accounts that need to be warm before the start of the execution.\n\n#### Message Type : Contract Creation\n\nIn the context of the Ethereum Yellow Paper, contract creation is represented by the function:\n\n$$\n\\Lambda(\\sigma, A, s, o, g, p, v, i, e, \\zeta, w) \\\\ or \\\\\n\\Lambda(state_{\\sigma}, AccruedSubState_{A} , sender_s , originalTransactor_o ,\\\\ availableGas_g , effectiveGasPrice_p , \\\\ endowment_v, []evmInitCodeByteArray_i , stackDepth_e , \\\\ saltForNewAccountAddress_{\\zeta}, stateModificationPermission_w)\n$$\n\n| $\\Lambda$ Call Parameter | Mapping | Notes |\n| ----------------------------------------- | -------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- |\n| $state_{\\sigma}$ | $I_{state}$ | The current state before contract creation begins. |\n| $AccruedSubState_{A}$ | $A^0$ | Represents the initial substate. |\n| $sender_s$ | $I_{origin}$ | The origin address of the transaction, initiating the contract creation. |\n| $originalTransactor_o$ | $I_{origin}$ | The original transactor, identical to the sender in direct transactions. |\n| $availableGas_g$ | $T_{gasLimit} - intrinsicCost$ | The gas available for the contract creation, after deducting the intrinsic cost of the transaction. |\n| $effectiveGasPrice_p$ | $I_{gasPrice}$ | The gas price set for the transaction. |\n| $endowment_v$ | $T_{value}$ | The value transferred to the new contract. |\n| $[]evmInitCodeByteArray_i$ | $T_{CALLDATA}$ | The initialization bytecode for the new contract. |\n| $stackDepth_e$ | 0 | The depth of the call stack at the point of contract creation; initially 0. |\n| $saltForNewAccountAddress_{\\zeta}$ | $\\emptyset$ | Salt used for generating the new contract's address, non empty for create2 operations. |\n| $stateModificationPermission_w$ | True, inversely referred by the `is_static` parameter in the Message object, which is set to false | Indicates if the contract creation can modify the state. |\n\nNote: $originalTransactor_o$ can differ from $sender_s$ when the message is not directly triggered by a transaction but rather comes from the execution of EVM code, indicating the versatility of message origination within the EVM execution context.\n\nThe process of creating a contract begins with determining the contract's address. In EELS, this task is part of message preparation. Other clients may handle it at a different stage. The steps are as follows:\n\n1. **Compute the Contract Address:**\n\n - The contract address is [computed](https://github.com/ethereum/execution-specs/blob/db87f1b1d21f61275fc34b08de1735889c01f018/src/ethereum/cancun/utils/address.py#L42) by hashing the sender's address and nonce (decremented by one, as the nonce is incremented prior to this operation) using the formula: $KEC(RLP([Sender_{address} , Sender_{nonce} - 1]))$. This adjustment accounts for the nonce at the transaction's issuance.\n - Next, extract the last 20 bytes of this hash: $KEC(RLP([Sender_{address} , Sender_{nonce} - 1]))[-20:]$.\n - If the resulting length is less than 20 bytes, left-pad with zero-byte words to form a 20-byte address.\n\n2. **Initialize the New Account:**\n\n$$\n\\sigma^*[newAccount] \\equiv ( Nonce_{=1}, Balance_{=preexistingValue + T_{value} }, Storage_{=TRIE(\\empty)}, CodeHash_{=KEC(())})\n$$\n\nThe state of the new account is established with:\n\n- A nonce set to 1.\n- The balance set to the sum of the transferred value and any pre-existing balance.\n- An empty storage.\n- A code hash derived from an empty tuple: KEC(()).\n\n3. **Update the Sender's Balance:**\n The sender's balance is adjusted by subtracting the transaction value:\n\n$$\n\\sigma^*[sender]_{balance} \\equiv \\sigma[sender]_{balance} - T_{value}\n$$\n\n4. **Account Initialization:**\n Finally, the account is initialized through the execution of the EVM initialization code byte array $[]evmInitCodeByteArray_i$ during the main execution cycle.\n\n#### Message Type: Call\n\nIn the context of the Ethereum Yellow Paper, a message call is represented by the function:\n\n$$\n\\Theta(\\sigma, A, s, o, r, c, g, p, v, \\tilde{v}, d, e, w) \\\\ or \\\\\n\\Theta(state_{\\sigma}, AccruedSubState_{A}, sender_s, originalTransactor_o, recipient_r, \\\\ codeAddress_c, availableGas_g, effectiveGasPrice_p, value_v, \\\\ apparentValue_{\\tilde{v}}, callData_d, stackDepth_e, stateModificationPermission_w)\n$$\n\n| $\\Theta$ Call Parameter | Mapping | Notes |\n| ----------------------- | ------- | ----- |\n| $state_{\\sigma}$ | $I_{state}$ | The current global state before message call execution begins. |\n| $AccruedSubState_{A}$ | $A$ | Represents the accumulated substate prior to the message call, including logs and refunds. |\n| $sender_s$ | $I_{sender}$ | The immediate caller of the message call, which may be an externally owned account or contract. |\n| $originalTransactor_o$ | $I_{origin}$ | The original external account that initiated the transaction and remains constant across calls. |\n| $recipient_r$ | $I_{recipient}$ | The address whose balance is adjusted and whose storage may be modified by the call. |\n| $codeAddress_c$ | $I_{code}$ | The address whose code is executed, typically equal to the recipient. |\n| $availableGas_g$ | $I_{gas}$ | The amount of gas available for execution of the message call. |\n| $effectiveGasPrice_p$ | $I_{gasPrice}$ | The gas price used for gas accounting during execution. |\n| $value_v$ | $I_{value}$ | The amount of ether transferred from the sender to the recipient. |\n| $apparentValue_{\\tilde{v}}$ | $I_{apparentValue}$ | The value visible to the executing code, differing in DELEGATECALL. |\n| $callData_d$ | $I_{callData}$ | Arbitrary-length byte array supplied as input data to the call. |\n| $stackDepth_e$ | $I_{depth}$ | The depth of the message call stack at the point of execution. |\n| $stateModificationPermission_w$ | $I_{isStatic}$ | Indicates whether state modification is permitted; false for STATICCALL. |\n\n---\n\n### Execution Result\n\nThe evaluation of a message call produces a 5-tuple: $(σ′, g′, A′, z, o)$. After execution begins, the EVM evaluates the call using the following logic:\n\n1. **Execution of Account Code**\n If the recipient account $r$ exists and contains code, the EVM executes the bytecode $\\sigma[r]_c$ using the execution function $\\Xi$. If no code exists, it is treated as a no-op (only value transfer occurs).\n\n2. **Exceptional Halting and State Reversion**\n If execution halts due to an exception (e.g., OOG), the state reverts to the point before the transfer:\n $$\\sigma' = \\sigma \\text{ if } \\sigma'' = \\emptyset, \\text{ else } \\sigma''$$\n\n3. **Gas and Substate Commitment**\n - **Gas:** If failed, all gas is consumed ($g'=0$). If successful, remaining gas $g''$ is returned.\n - **Substate:** Logs and refunds ($A'$) are only committed if execution is successful ($\\sigma'' \\neq \\emptyset$).\n\n4. **Execution Status Code ($z$)**\n - $z = 0$ if execution failed ($\\sigma'' = \\emptyset$).\n - $z = 1$ if execution succeeded.\n\n5. **Precompiled Contracts**\n If the recipient $r$ is within the set $\\pi = \\{1, 2, 3, 4, 5, 6, 7, 8, 9\\}$, execution is redirected to native functions:\n\n| Address | Function |\n| ------- | -------- |\n| 1 | ECDSA public key recovery |\n| 2 | SHA-256 hashing |\n| 3 | RIPEMD-160 hashing |\n| 4 | Identity function |\n| 5–8 | Elliptic curve operations (alt_bn128) |\n| 9 | BLAKE2 compression function |\n\n---\n\n**Implementation Reference:**\nThe semantics described above are implemented in the [Ethereum Execution Layer Specification (EELS)](https://github.com/ethereum/execution-specs). Relevant modules include:\n- `ethereum/execution/message.py`\n- `ethereum/execution/call.py`\n- `ethereum/execution/evm.py`\n### $T$ Execution Stage 3 : Main Execution ($\\Xi) $\n\n#### [Machine](/wiki/EL/evm?id=evm) State $\\mu$\n\n$$\\mu \\equiv (\\mu_{gasAvailable}, \\mu_{programCounter},\\\\ \\mu_{memoryContents}, \\mu_{activeWordsInMemory},\\\\ \\mu_{stackContents} ) $$\n| | initial Value | notes |\n|-|-|-|\n|$$\\mu$$ | | Initial Machine State |\n|$$\\mu'$$ | | Resultant Machine State after an operation where $\\mu' \\equiv \\mu \\space \\text{except :} \\\\ \\mu'_{gas} \\equiv \\mu_{gas} - C_{generalGasCost}(\\sigma, \\mu, A, I) $ |\n|$$\\mu_{gasAvailable}$$ | | total [gas available](/wiki/EL/evm?id=gas) for the transaction |\n|$$\\mu_{programCounter}$$ | 0 | [Natural number counter](/wiki/EL/evm?id=program-counter) to track the code position we are in , max number size is 256 bits |\n|$$\\mu_{memoryContents}$$ | $$[0_{256Bit}, ..., 0_{256Bit}]$$ | [word(256bit) Addressed byte array](/wiki/EL/evm?id=memory) |\n|$$\\mu_{activeWordsInMemory}$$ | 0 | Length of the active words in memory, expanded in chunks of 32bytes |\n|$$\\mu_{stackContents}$$ | | [Stack](/wiki/EL/evm?id=stack) item : word(256bit), Max Items = 1024 |\n|$$\\mu_{outputFromNormalHalting}$$ | () | Represents the output(bytes) from the last function call, determined by the normal halting function. While the EELS pyspec features a dedicated field in the EVM object for the output , Geth doesn't; instead, it utilizes the returnData field, which serves the same purpose.|\n\n#### Current Operation\n\nThe `currentOperation` is determined based on the position of the `programCounter` within the [bytecode](/wiki/EL/evm?id=evm-bytecode) array:\n\n$$ currentOperation \\equiv \\ w \\equiv\n\\begin{cases}\nI_{[byteCode]}[\\mu_{programCounter} ] & \\text{if} \\space \\mu_{programCounter} < length(I_{[byteCode]}) \\\\\nSTOP & \\text{otherwise}\n\\end{cases}\n$$\n\nThis logic fetches the current operation by accessing the byte at the programCounter's position within the bytecode array. If the programCounter exceeds the length of the bytecode, a STOP operation is issued to halt execution.\n\nConsider the Yellow Paper's definition of the add operator as an illustrative example:\n$$\\mu'_{stackContents}[0] \\equiv \\mu_{stackContents}[0] + \\mu_{stackContents}[1]$$\n\nThis representation implies a left-sided addition and removal in the stack, akin to queue operations. However, traditional stack operations add and remove items from the right. Translating this to stack-based operations:\n\n$$\nAdd \\Rightarrow\n$$\n\n$$\nx = Pop(\\mu_{stackContents}) \\\\\ny = Pop(\\mu_{stackContents_{itemsRemoved=1}}) \\\\\nresult = x + y \\\\\nPush(\\mu_{stackContents_{itemsRemoved=2}}, result)\n$$\n\n$$\n\\Rightarrow \\mu_{stackContents^{itemsAdded_{\\alpha}=1}_{itemsRemoved_{\\delta}=2}}\n$$\n\nWhen converting to code, the notation $\\mu_{s}[number]$ translates to $\\mu_{stackContents}[stackLength - 1 - number]$, aligning with the conventional understanding of stack operations.\n\nThe Yellow Paper elegantly notates stack-based operations and provides a framework for interpreting these operations within the execution cycle. It specifies that stack items are manipulated from the left-most, lower-indexed part of the array, with unaffected items remaining constant:\n\n$$\n\\begin{align}\n\\Delta \\equiv \\alpha^{itemsAdded}_w - \\delta^{itemsRemoved}_w \\quad (160) \\nonumber\\\\\n& \\nonumber \\\\\n\\mu'_{stackContents}.length \\equiv \\mu_{stackContents}.length + \\Delta \\quad (161) \\nonumber \\\\\n& \\nonumber \\\\\n\\forall x \\in [\\alpha^{itemsAdded}_w , \\mu'_{stackContents}.length) : \\mu'_{stackContents}[x] \\equiv \\mu_{stackContents}[x - \\Delta] \\quad (162) \\nonumber\n\\end{align}\n$$\n\nEquation 162 demonstrates that for each x within the specified range, the modified stack mirrors the original stack at position $x - \\Delta$, effectively tracking the original position of stack items post-operation. For example, adding an item [2] to an existing stack [10] results in [2,10], where the original item's new position aligns with $x=Delta$, maintaining the integrity of stack order post-operation.\n\n#### Single Execution Cycle\n\n$$\nO((\\sigma, \\mu, A, I)) \\equiv (\\sigma', \\mu', A', I) \\quad (159)\\\\\n$$\n\nWhere $O$ represents the Execution Cycle, encapsulating the outcome of a single cycle within the state machine. This cycle can modify all components of $\\mu$, with explicit specifications for changes to $\\mu_{gas}$ and $\\mu_{programCounter}$:\n\n##### Resultant Program Counter of a Single Execution Cycle\n\nThe following equation outlines how the execution cycle processes one instruction at a time:\n\n$$\n\\mu'_{programCounter} \\equiv\n\\begin{cases}\nJ_{JUMP}(\\mu) \\space \\text{if } currentOperation = JUMP \\\\\nJ_{JUMP1}(\\mu) \\space \\text{if } currentOperation = JUMP1 \\\\\nN(\\mu_{programCounter}, currentOperation) \\space \\text{otherwise}\n\\end{cases}\n$$\n\n$$\n\\text{Where, } \\\\\nNextValidInstruction_N(i_{=programCounter}, w_{=currentOperation}) \\equiv \\\\\n\\begin{cases}\n&\\\\\nprogramCounter + NumberOfBytes(currentOperation + Data_{currentOperation}) - NumberOfBytes(Operation_{PUSH1}) + 2 \\\\\n\\qquad \\text{if } currentOperation \\in [PUSH1,PUSH32] \\\\\n&\\\\\nprogramCounter + 1 \\space \\text{otherwise}\n\\end{cases}\n$$\n\n- Here if the Operation is $JUMP$, the $J_{JUMP}$ function will set the program counter to the value at the top of the stack.\n- For $JUMP1$ operations, the $J_{JUMP1}$ function sets the program counter to the value at the top of the stack only if the adjacent value in the stack is not 0. Otherwise, it increases the program counter by 1. If the current operation is neither $JUMP$ nor $JUMP1$, the program counter will be incremented by the NextValidInstruction function.\n\nThe NextValidInstruction function determines that if the current operation is within the range of all PUSH operations, we increment the program counter to the byte immediately following the current operation byte, accounting for the data associated with the operation. This data can range from 1 to 32 bytes, depending on the specific PUSH operation. If the operation is not a PUSH operation, we simply increment the program counter by 1, advancing to the next byte of the code. This process highlights that PUSH instructions are responsible for loading data onto the stack from the code.\n\nWhen the program counter executes a jump operation, it must target a valid jump destination. The $ValidJumpDestinations_{D}$ function specifies the set of all valid jump destinations.\n\n$$\nValidJumpDestinations_{D}(byteCode) \\equiv \\\\\nValidJumpDestinations_{D_J}(byteCode,index) \\equiv \\\\\n\\begin{cases}\n\\{\\} \\quad \\text{ if } index \\geq Length(byteCode) \\\\\n&\\\\\n\\{i\\} \\cup ValidJumpDestinations_{D_J}(byteCode,NextValidInstruction(index, byteCode[index])) \\\\\n\\space \\qquad \\text{if } byteCode[index] = JUMPDEST \\\\\n&\\\\\nValidJumpDestinations_{D_J}(byteCode,NextValidInstruction(index, byteCode[index])) \\space \\text{otherwise}\n\\end{cases}\n$$\n\nThis indicates that we include the index in the set if the bytecode at that index corresponds to a JUMPDEST operation. We continue adding these indices by recursively calling the $ValidValidJumpDestinations_{D_J}(byteCode, index)$ function with the index determined by the $NextValidInstruction$ function.\n\n##### Resultant Gas Consumption in a Single Execution Cycle\n\n$$\n\\mu'_{gas} \\equiv \\mu_{gas} - C_{gasCost}(\\sigma, \\mu, AccruedSubState, Environment_I)\n$$\n\nThe gas cost function, while not overly complex, includes various cases for different operations. It is succinctly defined in Appendix H of the Yellow Paper. In essence, it calculates the total cost of the current cycle by adding the cost of the current operation to the difference between the cost of active words in memory before and after the cycle (memory expansion cost).\n\nDifferent clients handle gas costs differently. In PySpec, various types of cost processing are integrated into the operations, while in Geth, gas costs are handled before the operation executes. Moreover, Geth distinguishes between [dynamic](https://github.com/ethereum/go-ethereum/blob/7bb3fb1481acbffd91afe19f802c29b1ae6ea60c/core/vm/interpreter.go#L257) costs used for memory expansion and [constant](https://github.com/ethereum/go-ethereum/blob/7bb3fb1481acbffd91afe19f802c29b1ae6ea60c/core/vm/interpreter.go#L224) gas associated with the base cost of the operation. Both types of costs are deducted using the [UseGas](https://github.com/ethereum/go-ethereum/blob/7bb3fb1481acbffd91afe19f802c29b1ae6ea60c/core/vm/contract.go#L161) function\n\n#### Program Execution $\\Xi$ :\n\n$$(\\sigma^{'}_{resultantState}, gas_{remaining}, A^{resultantAccruedSubState}, \\omicron^{Output})$$ $$\\equiv \\Xi(\\sigma,gas,A^{accruedSubState}, Environment_I)$$\n\nThe Program Execution function is defined formally by the function X, the only difference is $\\Xi$ calls X and returns the output of X removing the $Environment_I$ from the output tuple.\n\n##### Recursive Execution Function X\n\nX orchestrates the execution of the entire code. This is typically implemented by clients as a main loop iterating over the code. However, its definition is recursive:\n\n$$\nX((\\sigma,\\mu,AccruedSubState,Environment_I)) \\equiv \\nonumber \\\\\n\\begin{cases}\n&\\\\\n(\\empty, \\mu, AccruedSubState, Environment_I) \\\\ \\qquad \\text{if } Z_{exceptionalHalting}(\\sigma, \\mu, AccruedSubState, Environment_I) \\\\\n&\\\\\n(\\empty, \\mu', AccruedSubState, Environment_I, output ) \\\\ \\qquad \\text{if } currentOperation_w = REVERT \\\\\n&\\\\\nO(\\sigma, \\mu', AccruedSubState, Environment_I) . output \\\\ \\qquad \\text{if } output \\neq \\empty \\\\\n&\\\\\nX(O(\\sigma, \\mu', AccruedSubState, Environment_I)) \\\\ \\qquad \\text{otherwise}\n&\\\\\n\\end{cases}\n$$\n\n$$\n\\text{Where}, \\\\\n\\mu'_{returnData} \\equiv \\mu'_{outputFromNormalHalting} \\equiv output \\equiv H_{normalHaltingFunction}(\\mu,Environment_I)\n$$\n\n$$\nO(\\sigma,\\mu,A,I).output \\equiv O(\\sigma,\\mu,A,I,output)\n$$\n\n$$\n\\mu' \\equiv \\mu \\text{ except:} \\\\\n\\mu'_{gas} \\equiv \\mu_{gas} - C_{gasCostFunction}(\\sigma,\\mu,A,I) \\\\\n\\mu'_{activeWordsInMemory} \\equiv 32 * M_{memoryExpansionForRangeFunction}(\\mu_{activeWordsInMemory}, \\mu_{stackContents}[0], \\mu_{stackContents}[1])\n$$\n\n1. If the conditions for Exceptional Halting are met, return a tuple consisting of an empty state, the machine state, accrued sub state, environment, and an empty output.\n2. If the current Operation is $REVERT$, return a tuple consisting of an empty state, the machine state after deducting gas, accrued sub state, environment, and the machine output.\n3. If the machine output is not empty, the execution iterator function $O$ consumes the output.\n\n- For instance, if the current operation is a system operation such as CALL, CALLCODE, [DELEGATECALL](https://github.com/ethereum/execution-specs/blob/9c24cd78e49ce6cb9637d1dabb679a5099a58169/src/ethereum/cancun/vm/instructions/system.py#L542), or STATICCALL, these calls invoke the [generic call function](https://github.com/ethereum/execution-specs/blob/9c24cd78e49ce6cb9637d1dabb679a5099a58169/src/ethereum/cancun/vm/instructions/system.py#L267), setting up a new message and a child EVM process. The output of this process is then [written back into the memory](https://github.com/ethereum/execution-specs/blob/9c24cd78e49ce6cb9637d1dabb679a5099a58169/src/ethereum/cancun/vm/instructions/system.py#L325) of the parent EVM process, effectively consuming the output in one iteration of $O$, which may be utilized in the next iteration.\n\n4. In all other scenarios, we simply continue recursively calling the iterator function. In simpler terms, this means we proceed with the main interpreter loop\n\n##### Normal Halting H\n\nThe $H_{normalHaltingFunction}$ defines the halting behavior of the EVM under normal circumstances:\n\n$$\nH_{normalHaltingFunction}(\\mu, Environment_I) \\equiv\n$$\n\n$$\n\\begin{cases}\nH_{RETURN}(\\mu) & \\text{if } \\text{currentOperation} \\in \\{ \\text{RETURN}, \\text{REVERT} \\} \\\\\n() & \\text{if } \\text{currentOperation} \\in \\{ \\text{STOP}, \\text{SELFDESTRUCT} \\} \\\\\n\\empty & \\text{otherwise}\n\\end{cases}\n$$\n\nWhere:\n\n- $H_{RETURN}(\\mu) \\equiv \\mu'$\n\n- $\\Delta_{expansion}$ is calculated as:\n\n - $\\Delta_{expansion} \\equiv 32 \\times M_{memoryExpansionForRangeFunction}(length(\\mu_{memoryContents}), startPos, memorySize)$\n - $\\Delta_{expansion} \\in \\mathbb{N}$\n\n- $\\mu'$ is defined as:\n - $\\mu' \\equiv \\mu$ except:\n - $\\mu'_{memoryContents} \\equiv \\mu_{memoryContents} + [0_{\\text{word}_{256\\text{bit}}} ... 0_{\\text{word}_{256\\text{bit}}}]_{\\text{length}=\\Delta_{expansion}}$\n - $\\mu'_{output} \\equiv \\mu'_{memoryContents}[startPos : startPos + memorySize]$\n - $\\mu'_{gas} \\equiv \\mu_{gas} - \\text{memoryExpansionCost}$\n - $\\mu'_{running} \\equiv false$\n\nWhere:\n\n- $startPos \\equiv \\mu_{stackContents}[0]$\n- $memorySize \\equiv \\mu_{stackContents}[1]$\n\nThe function $M_{memoryExpansionForRangeFunction}(s,f,l)$ determines the memory expansion required to accommodate the range specified:\n\n$$\nM_{memoryExpansionForRangeFunction}(s,f,l) \\equiv\n$$\n\n$$\n\\begin{cases}\nS & \\text{if } l = 0 \\\\\n\\text{max}(s, \\lceil (f + l) / 32 \\rceil) & \\text{otherwise}\n\\end{cases}\n$$\n\nIn essence, the $H_{normalHaltingFunction}$ first sets the start index and length of the output based on the top two stack items. If memory expansion is needed to accommodate the output, it expands the memory accordingly, incurring memory expansion costs if necessary. Finally, it sets the EVM's output to the specified memory range.\n\n##### Exception Halting Z\n\n### $T$ Execution stage 4 : Provisional State $\\sigma_p$\n\nTODO\n\n### $T$ Execution stage 5 : Pre-Final State $\\sigma^*$\n\nTODO\n\n### $T$ Execution stage 6 : Final State $\\sigma'$\n\nTODO\n\n## Block Holistic Validity\n\nBlock Holistic Validity refers to the correctness of a block as a single atomic state transition, obtained by composing the ordered execution of all transactions and verifying that their aggregate effects are consistent with the commitments declared in the block header.\n\nAlthough the Yellow Paper specifies transaction execution and block validity through distinct functions, block holistic validity emerges from their composition and is formalized through the reconstruction and verification of execution results at the block level.\n\n---\n\n### State Initialization\n\nExecution of a block begins from an initial state derived from the parent block. The function $\\Gamma$ maps a block to its initial execution state:\n\n$$\n\\Gamma(B) \\equiv \n\\begin{cases} \n\\sigma_0 & \\text{if } P(B_H) = \\emptyset \\\\\n\\sigma_i \\text{ such that } \\text{TRIE}(LS(\\sigma_i)) = P(B_H)_H & \\text{otherwise}\n\\end{cases}\n$$\n\n| Symbol | Description |\n| ------ | ----------- |\n| $\\sigma_0$ | The genesis state. |\n| $P(B_H)_H$ | The parent block’s state root. |\n| $LS$ | The state-mapping function (World State). |\n\nThis ensures that all nodes begin execution from the same cryptographically committed state.\n\n---\n\n### Block Transition Function\n\nLet $B_T$ denote the ordered list of transactions in the block. Transactions are executed sequentially, where each transaction operates on the state produced by its predecessor. This sequential execution is captured by the block transition function $\\Pi$:\n\n$$\\Pi(\\sigma, B) \\equiv \\sigma'$$\n\nwhere $\\sigma'$ is the final post-transaction state obtained by applying all transactions in order, including any post-execution state transitions defined at the block level. As a consequence, transaction validity is context-dependent and sensitive to ordering and cumulative effects.\n\n### Gas Accumulation and Receipts\n\nEach transaction execution produces a receipt containing execution status, logs, and cumulative gas usage. Let $R[n]$ denote the cumulative gas used after executing the $n$-th transaction. Gas accumulation is defined recursively:\n\n$$\nR[n] \\equiv \n\\begin{cases} \n0 & \\text{if } n < 0 \\\\\n\\Upsilon^g(\\sigma[n-1], B_T[n]) + R[n-1] & \\text{otherwise}\n\\end{cases}\n$$\n\nwhere $\\Upsilon^g$ extracts the gas consumed by executing transaction $B_T[n]$ in state $\\sigma[n-1]$.\n\n---\n\n### Commitment Verification\n\nThe ordered sequence of transaction receipts and the final world state are committed using a Merkle–Patricia Trie. The block is valid only if these computed roots match the block header:\n\n1. **Receipts Root:** $B_{H_r} = \\text{TRIE}(LS(R))$\n2. **State Root:** $B_{H_s} = \\text{TRIE}(LS(\\sigma'))$\n\n**Validity Requirements:**\n* Computed receipts root must match the header.\n* Final state root must match the header.\n* Cumulative gas usage must respect the block gas limit ($R[n] \\le B_{H_l}$).\n\nBlock validity is **atomic**. The block-level transition function $\\Phi$ maps an initial state and block to a complete block result. The block is accepted if and only if all reconstruction, execution, accumulation, and commitment checks succeed. There is no notion of partial acceptance of transactions within a block.\n\n---\n\n**Implementation Reference:**\nThe semantics described above are based on the [Ethereum Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf):\n- **Section 12:** Block Finalization\n- **Section 12.1:** Executing Withdrawals\n- **Section 12.2:** Transaction Validation\n- **Section 12.3:** State Validation\n\n### Gas Accounting Examples\nUp to this point, we've talked about EL post-merge gas mechanics in a variety of scenarios. Let's tie it all together with some examples.\n\nNote: Each transaction type has distinct parameters and fee handling behavior.\n\n### Example 1: Simple ETH Transfer\n#### Supported Transaction Types\n- **Type 0**: Legacy transaction \n- **Type 1**: Legacy + Access List ([EIP-2930](https://eips.ethereum.org/EIPS/eip-2930)) \n- **Type 2**: EIP-1559 transaction ([EIP-1559](https://eips.ethereum.org/EIPS/eip-1559))\n\n#### Transaction Parameters (Defined by Sender)\n\n| Tx Type | Parameter | Description |\n|--------------|-------------------------|-------------------------------------------------------------------|\n| Type 0 / 1 / 2 | `gasLimit` | Max gas the transaction can consume |\n| Type 0 / 1 | `gasPrice` | Full gas price paid to the proposer |\n| Type 2 | `maxFeePerGas` | Max total fee per gas unit (includes base + tip) |\n| Type 2 | `maxPriorityFeePerGas` | Optional tip to incentivize block inclusion |\n\n#### Block Parameters (Defined by Protocol)\n\n| Tx Type | Parameter | Description |\n|------------|-------------|------------------------------------------------------|\n| Type 2 | `baseFee` | Dynamic base gas price per unit (burned by protocol) |\n\n#### Upfront Reservation\nAt this point, the transaction is ready for processing within a block. Initially, an upfront amount is reserved, meaning it's deducted from the sender.\n| Tx Type | Formula |\n|------------|----------------------------------|\n| Type 0 / 1 | `gasLimit × gasPrice` |\n| Type 2 | `gasLimit × maxFeePerGas` |\n\n#### Execution Phase\nAfter initial deductions, the transaction's execution cost is determined and the gas is either burned, awarded to the proposer, or returned to the sender.\n\n| Tx Type | Effective Gas Price | Actual Cost |\n|------------|------------------------------------------------------|--------------------------------|\n| Type 0 / 1 | `gasPrice` | `gasUsed × gasPrice` |\n| Type 2 | `baseFee + min(maxPriorityFeePerGas, maxFeePerGas − baseFee)` | `gasUsed × effectiveGasPrice` |\n\nNote: \n- For Type 0/1, the full amount is paid directly to the proposer. \nFor Type 2, the baseFee is burned and the tip, `min(maxPriorityFeePerGas, maxFeePerGas - baseFee)`, goes to the proposer. The effectiveGasPrice ensures the total gas cost stays within maxFeePerGas, potentially reducing the tip if the baseFee is high.\n\nThe refunded amount is calculated via `reserved − actualCost` and is returned to the sender.\n\n### Example 2: Blob Transaction\n\nBlob carrying transactions pay both the usual EVM gas fees and a separate blob gas fee for large data blobs. Note that there were no blobs for pre-EIP-1559 transaction types. In this example, we will only discuss fees associated with the blob.\n\n#### Blob Transaction Type\n- **Type 3**: EIP-4844 transaction ([EIP-4844](https://eips.ethereum.org/EIPS/eip-4844))\n\n#### Transaction Parameters\n- `blobVersionedHashes` – identifies each data blob. \n- `totalBlobGas` – computed as `GasPerBlob × numberOfBlobs`. \n- `maxFeePerBlobGas` – maximum gwei per blob gas unit the sender will pay.\n\n#### Block Parameters\n- `blobGasPrice` – dynamic per block blob gas unit price.\n\nInitially, an upfront amount is reserved, meaning it's deducted from the sender.\n- `reserved_blob = totalBlobGas × maxFeePerBlobGas`\n\n#### Execution Cost\n- `blobFee = totalBlobGas × blobGasPrice` and is fully burned by the protocol.\n\n#### Refund to Sender Calculation\n- `refund_blob = reserved_blob − blobFee` and is returned to sender.\n\nThese examples should help tie together how gas is handled during a transaction lifecycle.\n\n## Appendix\n\n### Code A\n\n```R\n##imports\n\nlibrary(plotly)\nlibrary(dplyr)\n\n## values for xi and rho\n## this is how '<-' assignment works in R\n\nELASTICITY_MULTIPLIER <- 2\nBASE_FEE_MAX_CHANGE_DENOMINATOR <- 8\n\n## Slightly modified function from the spec\n\ncalculate_base_fee_per_gas <- function(parent_gas_limit, parent_gas_used, parent_base_fee_per_gas, max_change_denom = BASE_FEE_MAX_CHANGE_DENOMINATOR , elasticity_multiplier = ELASTICITY_MULTIPLIER) {\n\n # %/% == // (in python) == floor\n\n parent_gas_target <- parent_gas_limit %/% elasticity_multiplier\n if (parent_gas_used == parent_gas_target) {\n expected_base_fee_per_gas <- parent_base_fee_per_gas\n } else if (parent_gas_used > parent_gas_target) {\n gas_used_delta <- parent_gas_used - parent_gas_target\n parent_fee_gas_delta <- parent_base_fee_per_gas * gas_used_delta\n target_fee_gas_delta <- parent_fee_gas_delta %/% parent_gas_target\n base_fee_per_gas_delta <- max(target_fee_gas_delta %/% max_change_denom, 1)\n expected_base_fee_per_gas <- parent_base_fee_per_gas + base_fee_per_gas_delta\n } else {\n gas_used_delta <- parent_gas_target - parent_gas_used\n parent_fee_gas_delta <- parent_base_fee_per_gas * gas_used_delta\n target_fee_gas_delta <- parent_fee_gas_delta %/% parent_gas_target\n base_fee_per_gas_delta <- target_fee_gas_delta %/% BASE_FEE_MAX_CHANGE_DENOMINATOR\n expected_base_fee_per_gas <- parent_base_fee_per_gas - base_fee_per_gas_delta\n }\n return(expected_base_fee_per_gas)\n}\n```\n\nAfter defining the model in R, we proceed by simulating the function across a range of gasused scenarios:\n\n````R\nparent_gas_limit <- 30000 # Fixed for simplification\n\n## lets see the effect on 100 to see the percentage effect this function has on fee\nparent_base_fee_per_gas <- 100\n\n## note gas used can not go below the minimum limit of 5k ,\n## therefore we can just count from 5k to 30k by ones for complete precision\n\nseq_parent_gas_used <- seq(5000, parent_gas_limit, by = 1) # creates a vector / column\n\n## add the vector / column to the data frame\n\ndata <- expand.grid(parent_gas_used = seq_parent_gas_used)\n\n## apply the function we created above and collect it in a new column\n\ndata$expected_base_fee <- mapply(calculate_base_fee_per_gas, parent_gas_limit, data$parent_gas_used, parent_base_fee_per_gas)\n````\n\nThat's all for prep , now let's plot and observe by doing a scatter plot which will reveal any shape this function produces over a range; given the constraints.\n\n```R\nfig <- plot_ly(data, x = ~parent_gas_used, y = ~expected_base_fee, type = 'scatter', mode = 'markers') # scatter plot\n\n## %>% is a pipe operater from dplyr , used extensively in R codebases it's like the pipe | operator used in shell\n\nfig <- fig %>% layout(xaxis = list(title = \"Parent Gas Used\"),\n yaxis = list(title = \"Expected Base Fee \"))\n\n## display the plot\nfig\n```\n\n### Code B\n\n````r\n\nlibrary(forcats)\nlibrary(ggplot2)\nlibrary(scales)\nlibrary(viridis)\n\n## Initial parameters\ninitial_gas_limit <- 30000000\ninitial_base_fee <- 100\nnum_blocks <- 100000\n\n## Sequence of blocks\nblocks <- 1:num_blocks\n\nmax_natural_number <- 2^256\n\n## Calculate gas limit for each block\ngas_limits <- numeric(length = num_blocks)\nexpected_base_fee <- numeric(length = num_blocks)\ngas_limits[1] <- initial_gas_limit\nexpected_base_fee[1] <- initial_base_fee\n\nfor (i in 2:num_blocks) {\n\n # apply max change to gas_limit at each block\n gas_limits[i] <- gas_limits[i-1] + gas_limits[i-1] %/% 1024\n\n\n # Check if the previous expected_base_fee has already reached the threshold\n if (expected_base_fee[i-1] >= max_natural_number) {\n # Once max_natural_number is reached or exceeded, stop increasing expected_base_fee\n expected_base_fee[i] <- expected_base_fee[i-1]\n } else {\n # Calculate expected_base_fee normally until the threshold is reached\n expected_base_fee[i] <- calculate_base_fee_per_gas(gas_limits[i-1], gas_limits[i], expected_base_fee[i-1])\n }\n}\n\n## Create data frame for plotting\ndata <- data.frame(Block = blocks, GasLimit = gas_limits, BaseFee = expected_base_fee)\n\n## Saner labels\nlabel_custom <- function(labels) {\n sapply(labels, function(label) {\n if (is.na(label)) {\n return(NA)\n }\n if (label >= 1e46) {\n paste(format(round(label / 1e46, 2), nsmall = 2), \"× 10^46\", sep = \"\")\n } else if (label >= 1e12) {\n paste(format(round(label / 1e12, 2), nsmall = 2), \"T\", sep = \"\") # Trillions\n } else if (label >= 1e9) {\n paste(format(round(label / 1e9, 1), nsmall = 1), \"Billion\", sep = \"\") # Million\n } else if (label >= 1e6) {\n paste(format(round(label / 1e6, 1), nsmall = 1), \"Mil\", sep = \"\") # Million\n } else if (label >= 1e3) {\n paste(format(round(label / 1e3, 1), nsmall = 1), \"k\", sep = \"\") # Thousand\n } else {\n as.character(label)\n }\n })\n}\n\n## Bin the ranges we want to observe\ndata_ranges <- data %>%\n mutate(Range = case_when(\n Block <= 1000 ~ \"1-1000\",\n Block <= 10000 ~ \"1001-10000\",\n Block <= 100000 ~ \"10001-100000\"\n ))\n\n## Rearrange the bins to control where the plots are displayed\ndata_ranges$Range <- fct_relevel(data_ranges$Range, \"1-1000\", \"1001-10000\", \"10001-100000\")\n\n## Grammar of graphics we can just + the features we want in the plot\nplot <- ggplot(data_ranges, aes(x = Block, y = GasLimit, color = BaseFee)) +\n geom_line() +\n facet_wrap(~Range, scales = \"free\") + # Using free to allow each facet to have its own x-axis scale\n labs(title = \"Gas Limit Over Different Block Ranges\",\n x = \"Block Number\",\n y = \"Gas Limit\") +\n scale_x_continuous(labels = label_custom) + # Use custom label function for x-axis\n scale_y_continuous(labels = label_custom) + # Use custom label function for y-axis\n scale_color_gradientn(colors = viridis(8), trans = \"log10\",\n breaks = c(1e3, 1e10, 1e20, 1e40, 1e60, 1e76),\n labels = c(\"100\", \"10^10\", \"10^20\", \"10^40\", \"10^60\", \"10^76\")) +\n theme_bw()\n\n## To view\nplot\n\n## Save to file\nggsave(\"plot_gas_limit.png\", plot, width = 7, height = 5)\n\n````\n\n### Code C\n\n````r\n## we are observing the effects of this parameter\n## it's set at 8 but lets see its effect in the range of [2,4, .. ,8, .. ,12]\nseq_max_change_denom <- seq(2, 12, by = 2)\n\nparent_gas_limit <- 3 * 10^6\nseq_parent_gas_used <- seq(5000, parent_gas_limit, by = 100)\n\nparent_base_fee_per_gas <- 100\n\ndata <- expand.grid( parent_gas_used = seq_parent_gas_used, base_fee_max_change_denominator = seq_max_change_denom)\n\ndata$expected_base_fee <- mapply(calculate_base_fee_per_gas, parent_gas_limit, data$parent_gas_used, parent_base_fee_per_gas, data$ base_fee_max_change_denominator)\n$`\n\nThat's all for data prep , now lets plot:\n\n```r\nplot <- ggplot(data, aes(x = parent_gas_used, y = expected_base_fee, color = as.factor(base_fee_max_change_denominator))) +\n geom_point() +\n scale_color_brewer(palette = \"Spectral\") +\n theme_minimal() +\n labs(color = \"Base Fee Max Change Denominator\") +\n theme_bw()\n\nplot\n```\n\n### Code D\n\n````r\nseq_elasticity_multiplier <- seq(1, 6, by = 1)\nseq_max_change_denom <- seq(2, 12, by = 2)\n\nparent_gas_limit <- 3 * 10^6\nseq_parent_gas_used <- seq(5000, parent_gas_limit, by = 500)\n\nparent_base_fee_per_gas <- 100\n\ndata <- expand.grid( parent_gas_used = seq_parent_gas_used, base_fee_max_change_denominator = seq_max_change_denom, elasticity_multiplier = seq_elasticity_multiplier)\n\ndata```expected_base_fee <- mapply(calculate_base_fee_per_gas, parent_gas_limit, data$parent_gas_used, parent_base_fee_per_gas, data$base_fee_max_change_denominator, data$ elasticity_multiplier)\n\nplot <- ggplot(data, aes(x = parent_gas_used, y = expected_base_fee, color = as.factor(base_fee_max_change_denominator))) +\n geom_point() +\n facet_wrap(~elasticity_multiplier) + # we break the plots out by the this facet\n scale_color_brewer(palette = \"Spectral\") +\n theme_minimal() +\n labs(color = \"Base Fee Max Change Denominator\") +\n theme_bw()\n\nggsave(\"rho-xi.png\", plot, width = 14, height = 10)\n\n$`\n\n### Code E\n\n````r\nlibrary(ggplot2)\nlibrary(tidyr)\n\n## fake exponential or taylor series expansion function\nfake_exponential <- function(factor, numerator, denominator) {\n i <- 1\n output <- 0\n numerator_accum <- factor * denominator\n while(numerator_accum > 0){\n output <- output + numerator_accum\n numerator_accum <- (numerator_accum * numerator) %/% (denominator * i)\n i <- i + 1\n }\n output %/% denominator\n}\n\n## Blob Gas Target\ntarget_blob_gas_per_block <- 393216\n\n## Blob Gas Max Limit\nmax_blob_gas_per_block <- 786432\n\n # Used in header Verificaton\n calc_excess_blob_gas <- function(parent_excess_blob_gas, parent_gas_used) {\n if (parent_gas_used + parent_excess_blob_gas < target_blob_gas_per_block) {\n return(0)\n } else {\n return(parent_excess_blob_gas + parent_gas_used - target_blob_gas_per_block)\n }\n }\n\n## This is how EL determines the Blob Gas Price\ncancun_blob_gas_price <- function(excess_blob_gas) {\n fake_exponential(1, excess_blob_gas, 3338477)\n}\n\n## we got from zero to Max each step increasing by 1000\nparent_gas_used <- seq(0, max_blob_gas_per_block, by = 1000)\n## A column of the same Length\nexcess_blob_gas <- numeric(length = length(parent_gas_used))\nexcess_blob_gas[1] <- 0\n\n## We get the T+1(time + 1) excess gas by using values from before\nfor (i in 2:length(parent_gas_used)) {\n excess_blob_gas[i] <- calc_excess_blob_gas(excess_blob_gas[i - 1],\n parent_gas_used[i - 1])\n}\n\ndata_blob_price <- expand.grid(parent_gas_used = parent_gas_used)\ndata_blob_price```excess_blob_gas <- excess_blob_gas\n\n## Apply the EL gas price function\ndata_blob_price$ blob_gas_price <- mapply(cancun_blob_gas_price,\n data_blob_price$excess_blob_gas)\n\n## Each row represents a block\ndata_blob_price$BlockNumber <- seq_along(data_blob_price$parent_gas_used)\n\n## we collapse the 3 columns into 1 Parameter Column\ndata_long <- pivot_longer(data_blob_price,\n cols = c(parent_gas_used,\n excess_blob_gas,\n blob_gas_price),\n names_to = \"Parameter\",\n values_to = \"Value\")\n\nggplot(data_long, aes(x = BlockNumber, y = Value)) +\n geom_line() +\n facet_wrap(~ Parameter, scales = \"free_y\") + # We break the charts out based on the Parameter Column\n theme_minimal() +\n scale_y_continuous(labels = scales::label_number()) +\n labs(title = \"Dynamic Trends in Blob Gas Consumption & Price Over Time\",\n x = \"Block Number\",\n y = \"Parameter Value\") +\n geom_text(data = subset(data_long, Parameter == \"blob_gas_price\" &\n BlockNumber == min(BlockNumber)),\n aes(label = \"blobGasPrice = 1\", y = 0),\n vjust = -1, hjust = -0.1, size = 3)\n\n````\n\n### Code F\n\n````r\nnormalize <- function(x) {\n return((x - min(x)) / (max(x) - min(x)))\n}\n\ndata_blob_price$parent_gas_used_normalized <- normalize(data_blob_price$parent_gas_used)\ndata_blob_price$excess_blob_gas_normalized <- normalize(data_blob_price$excess_blob_gas)\ndata_blob_price$blob_gas_price_normalized <- normalize(data_blob_price$blob_gas_price)\n\nggplot(data_blob_price, aes(x = BlockNumber)) +\n geom_line(aes(y = parent_gas_used_normalized, color = \"Parent Gas Used\")) +\n geom_line(aes(y = excess_blob_gas_normalized, color = \"Excess Blob Gas\")) +\n geom_line(aes(y = blob_gas_price_normalized, color = \"Blob Gas Price\")) +\n theme_minimal() +\n labs(title = \"Normalized Trends Over Blocks\", x = \"Block Number\", y = \"Normalized Value\", color = \"Parameter\")\n````\n\n### Code for formatting document\n\nFormatting are messing up the latex code in this document the below script formats katex documents correctly.\n\n````bash\n#!/bin/bash\n\nsed -i.bck -E ':a;N;$!ba;s/\\$\\$([^$]+)\\$\\$/```code2 \\1```/g; s/\\$([^$]+)\\$/```code1 \\1```/g' $1\nprettier --write $1\nsed -i -E ':a;N;$!ba;s/```code1([^`]*)```/\\$\\1\\$/g' $1\nsed -i -E ':a;N;$!ba;s/```code2([^`]*)```/\\$\\$\\1\\$\\$/g' $1\nsed -i -E ':a;N;$!ba;s/`code1([^`]*)`/\\$\\1\\$/g' $1\nsed -i -E ':a;N;$!ba;s/`code2([^`]*)`/\\$\\$\\1\\$\\$/g' $1\nsed -i -E 's/(\\$+)\\s*([^$]+?)\\s*(\\$+)/\\1\\2\\3/g' $1\n````\n\n### Resources\n- https://archive.devcon.org/archive/watch/6/eels-the-future-of-execution-layer-specifications/?tab=YouTube\n- [EIP‑1559](https://eips.ethereum.org/EIPS/eip-1559) • [archived](https://web.archive.org/web/20230101000000/https://eips.ethereum.org/EIPS/eip-1559)\n- [EIP‑4844](https://eips.ethereum.org/EIPS/eip-4844) • [archived](https://web.archive.org/web/20230701000000/https://eips.ethereum.org/EIPS/eip-4844)\n- [Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf) • [archived](https://web.archive.org/web/20240310000000/https://ethereum.github.io/yellowpaper/paper.pdf)\n- [EL Specs](https://github.com/ethereum/execution-specs) • [archived](https://web.archive.org/web/20240501000000/https://github.com/ethereum/execution-specs)\n\n\n> [!NOTE]\n> All the topics in this PR are open for collaboration on a separate branch\n\n$$\n\n$$\n" }, { "path": "docs/wiki/EL/engine-api.md", "content": "# Engine API\n\n> [!WARNING]\n> The Glamsterdam section of this page covers active areas of research (EIP-7732 ePBS and EIP-7928 BALs). Those sections may be outdated at time of reading and are subject to future updates as the design space evolves.\n\n**Prerequisite reading:** [EL Architecture](/wiki/EL/el-architecture.md)\n\nThe Engine API is the authenticated communication interface between the Consensus Layer (CL) and the Execution Layer (EL), introduced at The Merge. The CL drives the EL's block building, validation, and fork choice through this interface. It tells the EL which chain is canonical, asks it to build new blocks, and sends received blocks for validation.\n\n## Architecture\n\n### Network Isolation\n\nThe Engine API is served on a **dedicated port (default: 8551)**, strictly separate from the public-facing JSON-RPC API (default: 8545). This isolation is a security requirement. Shared ports would allow public traffic or deliberate DoS floods to starve the consensus dialogue, causing missed proposals and attestations.\n\n### Communication Protocols\n\n| Protocol | Authentication | Notes |\n|----------|---------------|-------|\n| HTTP | JWT on every request | Standard; stateless |\n| WebSocket | JWT on initial handshake only | Persistent connection; no per-frame auth |\n| IPC | None | Same-machine only; filesystem permissions provide isolation |\n\n### Ancillary eth_ Methods\n\nThe spec requires the EL to expose all nine of the following `eth_` methods on the authenticated Engine API port, enabling the CL to query chain state without a separate connection:\n\n`eth_blockNumber`, `eth_call`, `eth_chainId`, `eth_getCode`, `eth_getBlockByHash`, `eth_getBlockByNumber`, `eth_getLogs`, `eth_sendRawTransaction`, `eth_syncing`\n\n`eth_getLogs` is critical for CL monitoring of the deposit contract (pre-Electra). `eth_call` enables the CL to verify EIP-7002 withdrawal credentials without broadcasting transactions.\n\n## Authentication\n\nThe CL and EL share a 256-bit (32-byte) hex-encoded JWT secret, configured via a `--jwt-secret` CLI flag pointing to a `jwt.hex` file. If omitted, the EL auto-generates a random secret for that session and writes it to `jwt.hex` in its data directory.\n\n**Algorithm**: The EL must enforce **HS256** (HMAC-SHA256). Any JWT specifying `alg: none` must be immediately rejected to prevent authentication bypass.\n\n**Replay protection**: Every JWT must include an `iat` (issued-at) claim. The EL must reject any request where the token's `iat` deviates by more than **±60 seconds** from the EL's local clock. This prevents captured tokens from being replayed to induce chain reorganizations.\n\nOptional claims (`id`, `clv`) may be included for telemetry but are not validated for access control.\n\n## Capability Negotiation\n\n### engine_exchangeCapabilities\n\n`engine_exchangeCapabilities` has no version suffix. It is the only Engine API method without one. It lets clients discover each other's supported method versions.\n\n- The EL **must** support this method; the CL may call it optionally\n- Each party sends an array of their supported method names with version suffixes (e.g. `[\"engine_newPayloadV3\", \"engine_newPayloadV4\"]`)\n- The EL responds with its own list. `engine_exchangeCapabilities` itself **must not** appear in the response.\n- The EL must not log errors if this method is never called (backward compatibility)\n\n### engine_getClientVersionV1\n\nAn optional method allowing the CL and EL to identify each other's software. Each side returns a `ClientVersionV1` structure with a two-letter client code, human-readable name, version string, and 4-byte commit hash. The compact identifiers are designed to fit in the 32-byte beacon block graffiti field for network diversity tracking.\n\n| Code | EL Client | Code | CL Client |\n|------|-----------|------|-----------|\n| `BU` | Besu | `GR` | Grandine |\n| `EG` | Erigon | `LH` | Lighthouse |\n| `EJ` | EthereumJS | `LS` | Lodestar |\n| `EX` | Ethrex | `NB` | Nimbus |\n| `GE` | Geth | `PM` | Prysm |\n| `NM` | Nethermind | `TK` | Teku |\n| `RH` | Reth | | |\n| `TE` | Trin-Execution | | |\n\nThe EL must not log errors if this method is never called.\n\n## Core Methods\n\n### engine_forkchoiceUpdatedV3\n\nUpdates the EL's canonical chain view and optionally initiates block building.\n\n**Parameters:**\n- `forkchoiceState`: `{headBlockHash, safeBlockHash, finalizedBlockHash}`\n- `payloadAttributes` (optional): `{timestamp, prevRandao, suggestedFeeRecipient, withdrawals, parentBeaconBlockRoot}`. If provided, the EL starts building a payload and returns a `payloadId`.\n\n**Returns:** `{payloadStatus, payloadId}`\n\n`engine_forkchoiceUpdatedV3` returns only `VALID`, `INVALID`, or `SYNCING`. It never returns `ACCEPTED`. A fork choice update is an authoritative command to reorganize or extend the canonical chain, so the EL must fully resolve the head block's state before executing the update. `ACCEPTED` is exclusive to `engine_newPayload`.\n\n### Payload Status Values\n\n| Status | Returned by | Meaning |\n|--------|-------------|---------|\n| `VALID` | both | Block and all ancestors fully downloaded and EVM-verified |\n| `INVALID` | both | Violates consensus rules; `latestValidHash` identifies the highest valid ancestor for fork recovery |\n| `SYNCING` | both | Required ancestor data is missing locally; EL has begun fetching from p2p |\n| `ACCEPTED` | newPayload only | Block hash valid, all transactions non-zero length, payload does **not** extend the canonical chain (it is on a side branch), ancestors are locally available. EVM execution is deliberately deferred until fork choice may pivot to this branch. |\n\n**ACCEPTED vs SYNCING**: `SYNCING` means the EL cannot accept the block because its chain history is missing. `ACCEPTED` means the ancestry is intact. The EL chose not to run full EVM validation because this is currently a non-canonical side branch. If LMD-GHOST later pivots to this branch, the EL executes the deferred state transitions.\n\n### engine_newPayloadV4\n\nDelivers an execution payload from a received beacon block to the EL for validation.\n\n**Parameters:**\n- `executionPayload`: the full block\n- `expectedBlobVersionedHashes`: ordered list of blob versioned hashes\n- `parentBeaconBlockRoot`: parent beacon block root (EIP-4788)\n- `executionRequests`: EL-generated requests for the CL (Electra+)\n\n**Validation:**\n- Executes all transactions and verifies the resulting state root\n- **Blob hash validation**: extracts `blob_versioned_hashes` from every blob-carrying transaction in the payload, preserving inclusion order, concatenates them, and compares against `expectedBlobVersionedHashes`. Any mismatch or ordering difference returns `INVALID`.\n\n**Returns:** `VALID`, `INVALID`, `SYNCING`, or `ACCEPTED`\n\n### engine_getPayloadV4\n\nRetrieves a payload the EL built after a `forkchoiceUpdated` call with `payloadAttributes`.\n\n**Parameters:** `payloadId` is the 8-byte ID returned by `engine_forkchoiceUpdatedV3`.\n\n**Returns:**\n- `executionPayload`: the assembled block\n- `blockValue`: total wei in priority fees accruing to `feeRecipient` (256-bit quantity)\n- `blobsBundle`: `{commitments, proofs, blobs}`. Contains 48-byte KZG commitments, 48-byte KZG proofs, and 131,072-byte blob data for the CL to build blob sidecars.\n- `shouldOverrideBuilder`: a boolean **suggestion** from the EL that the locally built payload should be used instead of an external MEV-Boost bid. The CL may or may not act on this. It is one input into the CL's decision, not a command. The EL sets it using implementation-defined heuristics (e.g. a high-value transaction has been persistently excluded from builder bids). If the EL implements no heuristic, it must default to `false`.\n- `executionRequests`: EL-generated requests (Electra+)\n\n## Execution Requests (EIP-7685)\n\nIntroduced in V4 (Prague/Electra), execution requests allow EVM smart contracts to trigger consensus-layer state changes. Each request is `request_type ++ request_data` where `request_type` is a 1-byte prefix.\n\n**Supported types in Electra:**\n\n| Type | EIP | Description |\n|------|-----|-------------|\n| `0x00` | EIP-6110 | **Deposit requests**: EL pushes deposit events to the CL directly, replacing CL log polling. Reduces validator activation time from ~12 hours to ~13 minutes. Max per payload: `MAX_DEPOSIT_REQUESTS_PER_PAYLOAD = 8,192`. |\n| `0x01` | EIP-7002 | **Withdrawal requests**: Smart contracts holding `0x01` withdrawal credentials can trigger partial or full validator exits from the EVM. Processed via predeploy at `0x00000961Ef480Eb55e80D19ad83579A64c007002`. Target: 2/block; max: 16/block. Fee: `fake_exponential(1_wei, excess, 17)`, near 1 wei under normal load and exponentially expensive under sustained demand. System call gas: 30,000,000 (excluded from block gas accounting). |\n| `0x02` | EIP-7251 | **Consolidation requests**: Merge multiple 32 ETH validators into a single compounding validator (up to 2048 ETH effective balance). Target: 1/block; max: 2/block. Pending queue hard limit: `PENDING_CONSOLIDATIONS_LIMIT = 262,144` (2^18). |\n\n**Ordering and validation rules**: The `executionRequests` array must be:\n- Sorted in **strictly ascending order** by `request_type`\n- Each `request_type` byte appears **at most once** (no duplicates)\n- No element with empty `request_data` (elements of length <= 1 byte must be excluded)\n\nAny violation returns `-32602: Invalid params`. The EL also computes a `requests_hash` (SHA-256 over the sorted list) and validates it against the block header; a mismatch returns `INVALID`. For a block with no requests, the hash defaults to `sha256(\"\") = 0xe3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855`.\n\n## Version History\n\n| Version | EL Fork | CL Fork | Key Changes |\n|---------|---------|---------|-------------|\n| V1 | Paris | Bellatrix | Initial post-Merge: `forkchoiceUpdated`, `newPayload`, `getPayload` |\n| V2 | Shanghai | Capella | Added `withdrawals` to payload attributes and execution payload |\n| V3 | Cancun | Deneb | Added `blobVersionedHashes`, `parentBeaconBlockRoot`; `executionPayload` gains `blobGasUsed`, `excessBlobGas`; `getPayload` returns `BlobsBundleV1` |\n| V4 | Prague | Electra | Added `executionRequests` (EIP-7685) |\n\n## Slot Lifecycle\n\nThe Engine API operates within a strict 12-second slot heartbeat. For a proposer node:\n\n| Time | Action |\n|------|--------|\n| **t = 0s** | Slot begins. CL calls `engine_forkchoiceUpdatedV3` with `payloadAttributes`. EL returns `payloadId`. |\n| **t = 1-3s** | EL builds the payload: selects mempool transactions, executes them, computes state root. CL optionally queries external MEV relays. |\n| **t = 3s** | CL calls `engine_getPayloadV4`, wraps payload into a `BeaconBlock`, signs it, broadcasts. |\n| **t = 4s** | **Attestation deadline.** Other validators must have received the block, called `engine_newPayloadV4`, and received `VALID` by this point. Late blocks are not attested to and earn no inclusion revenue. |\n| **t = 4-12s** | CL calls `engine_forkchoiceUpdatedV3` (without `payloadAttributes`) to set the new block as head. |\n\nNon-proposer nodes skip the first three steps and only perform `engine_newPayloadV4` followed by `engine_forkchoiceUpdatedV3`.\n\n### Optimistic Sync\n\nDuring heavy load, the CL may import a beacon block optimistically without waiting for full EVM execution. If the EL later returns `INVALID`, the CL reorgs back to `latestValidHash`. The maximum optimistic import depth is bounded by `SAFE_SLOTS_TO_IMPORT_OPTIMISTICALLY` (default: **128 slots**, ~25.6 minutes), configurable via `--safe-slots-to-import-optimistically`. This prevents \"fork choice poisoning\" attacks where a malicious peer feeds structurally valid but computationally invalid blocks at the chain tip.\n\n## Error Handling\n\n### JSON-RPC Error Codes\n\n| Code | Name | Trigger |\n|------|------|---------|\n| `-32700` to `-32603` | Standard JSON-RPC | Parse errors, invalid requests, method not found, invalid params, internal errors |\n| `-32000` | Server error | Generic EL failure; response **must** include a `data.err` string with diagnostic context (e.g. `\"LevelDB read failure\"`) |\n| `-38001` | Unknown payload | `engine_getPayload` called with a `payloadId` that has no active build process or has timed out |\n| `-38002` | Invalid forkchoice state | `forkchoiceState` hashes are logically inconsistent (e.g. `safeBlockHash` is not an ancestor of `headBlockHash`) |\n| `-38003` | Invalid payload attributes | `payloadAttributes` fields are structurally invalid or missing fork-required fields |\n| `-38004` | Too large request | An array parameter exceeds hardcoded memory constraints |\n| `-38005` | Unsupported fork | Payload timestamp does not align with the EL's active fork (e.g. a Deneb-format payload submitted before Deneb activation) |\n\n### Failure Modes\n\n**`SYNCING`**: CL retries `engine_forkchoiceUpdatedV3` until the EL catches up. Do not attest to or build on that block.\n\n**`INVALID`**: CL marks that block and all descendants as invalid, reverts fork choice to `latestValidHash`.\n\n**EL unreachable** (port down, JWT mismatch, crash): CL cannot propose or validate. Validators miss all duties until the connection is restored.\n\n## Future Upgrades\n\n### Fusaka (Fulu/Osaka, December 3, 2025, epoch 411392)\n\nThe Fusaka upgrade spans 13 EIPs covering DA scaling, execution performance, and protocol cleanup. Key Engine API impacts:\n\n**Data availability:**\n- **EIP-7594 (PeerDAS)**: Nodes sample small column subsets instead of downloading full blobs, enabling safe blob throughput increases. `engine_getPayloadBodiesByHashV2` and `engine_getPayloadBodiesByRangeV2` are updated to support PeerDAS cell proof structures.\n- **EIP-7918**: Blob base fee floor tied proportionally to the execution base fee, preventing blob fees from collapsing to 1 wei during low demand.\n- **EIP-7892 (BPO forks)**: Blob Parameter Only forks allow blob counts to be scaled post-Fusaka via lightweight network adjustments without triggering full hard forks. BPO1 and BPO2 activated shortly after Fusaka, raising blob targets to 10/15 and 14/21 respectively.\n\n**Execution performance:**\n- **EIP-7935**: Default block gas limit raised to **60M** (coordinated among clients, not a consensus rule).\n- **EIP-7825**: Transaction gas limit capped at **2^24 = 16,777,216 gas**. No single transaction can occupy an entire block.\n- **EIP-7934**: RLP execution block size capped at **8 MiB** (`MAX_RLP_BLOCK_SIZE = 10 MiB - 2 MiB safety margin`). The CL gossip protocol already drops blocks over 10 MiB; the 2 MiB margin reserves headroom for the beacon block, making the effective EL payload limit 8 MiB.\n- **EIP-7883**: MODEXP precompile repriced. Minimum gas raised from 200 to **500**, general cost formula **tripled**, and large-exponent multiplier raised from 8 to **16**.\n- **EIP-7823**: MODEXP inputs bounded at **8192 bits (1024 bytes)** per input (base, exponent, modulus). All historical real-world usage was under this limit.\n- **EIP-7917**: Deterministic proposer lookahead. The proposer schedule is known one full epoch in advance, improving MEV and PBS coordination.\n\n### Glamsterdam (post-Fusaka)\n\n**EIP-7732 (ePBS)** is the proposed Glamsterdam CL headliner. It moves PBS from the out-of-protocol MEV-Boost sidecar into the consensus layer, eliminating reliance on trusted relays. The Engine API slot lifecycle changes materially: the proposer receives only a signed **builder commitment** at t=3s and broadcasts it without the execution payload; the builder then reveals the full `ExecutionPayloadEnvelope` to the network after the t=4s attestation deadline. This prevents the proposer from stealing the builder's MEV while retaining the ability to attest. New Engine API methods handle commitment validation separately from full EVM execution.\n\n**EIP-7928 (Block-Level Access Lists)** is the proposed Glamsterdam EL headliner. Every block would include an explicit map of all addresses and storage slots accessed during execution, enabling:\n- Parallel pre-fetching of state before EVM execution\n- Parallel execution of non-conflicting transactions across CPU cores\n- Execution-less state verification for stateless and ZK clients\n\nThe Engine API would validate this by having the EL execute the payload, compute the access list internally, and verify it against the `blockAccessList` in the payload header. A mismatch returns `INVALID`. Both EIPs are draft proposals.\n\n## Resources\n\n- [Engine API specification (execution-apis)](https://github.com/ethereum/execution-apis/tree/main/src/engine)\n- [EIP-3675: Upgrade to Proof-of-Stake](https://eips.ethereum.org/EIPS/eip-3675)\n- [EIP-7685: General purpose EL requests](https://eips.ethereum.org/EIPS/eip-7685)\n- [EIP-7002: Execution layer triggerable withdrawals](https://eips.ethereum.org/EIPS/eip-7002)\n- [EIP-7607: Hardfork Meta - Fusaka](https://eips.ethereum.org/EIPS/eip-7607)\n- [EIP-7732: Enshrined Proposer-Builder Separation](https://eips.ethereum.org/EIPS/eip-7732)\n- [EIP-7928: Block-Level Access Lists](https://eips.ethereum.org/EIPS/eip-7928)\n- [Engine API visual guide](https://hackmd.io/@danielrachi/engine_api)\n" }, { "path": "docs/wiki/EL/eof.md", "content": "# EVM Object Format (EOF)\n\nThe EVM Object Format (EOF) is an extensible and versioned container format for EVM bytecode with a once-off validation at deploy time.\n\nCurrently, [EVM Bytecode](/wiki/EL/evm.md#evm-bytecode) is an unstructured sequence of instructions. EOF introduces the concept of a container, which brings structure to bytecode, making it easier to parse by the EVM and analyze. Its primary goal is to enable major upgrades to the EVM by allowing once-off code validation at deploy time and by strictly separating code from data.\n\nFor example, EOF1 bytecode begins with a 2-byte magic `0xEF00` and version, followed by a list of section headers and a `0x00` terminator. This structure allows EVM implementations to verify an entire contract's correctness at deploy time, including stack depth and structural validity, before any execution begins.\n```\n// Example layout of an EOF container (bytecode):\nMagic (0xEF00) | Version | (section_kind, section_size_or_sizes)+ | 0x00\n[types section] [code section 0] [code section 1] … [data section]\n```\n\n---\n\n## Purpose and Benefits\n\nEOF was designed to address several limitations of the original EVM bytecode format:\n\n- **Better Validation:** Enables thorough static analysis and validation of smart contracts before execution. It rejects truncated PUSH data or undefined opcodes, making every EOF contract provably valid on-chain.\n\n- **Improved Execution Efficiency:** Facilitates optimization of EVM execution through better-defined code sections and the removal of runtime JUMPDEST scans.\n\n- **Enhanced Security:** Reduces attack vectors by enforcing stricter code structure rules and eliminating legacy quirks (like SELFDESTRUCT or DELEGATECALL issues) through validation.\n\n- **Code/Data Separation:** By keeping data (e.g., compiler metadata) in a separate section, tools like verifiers and L2s can easily distinguish executable code from arbitrary data, improving both security and gas efficiency.\n\n---\n\n## Related EIPs and Implementations\n\nEOF is specified in several EIPs covering different features, changes to various opcodes, and introducing new ones. All these EIPs are tracked by a single meta EIP: [EIP-7692](https://eips.ethereum.org/EIPS/eip-7692).\n\n### Core Container & Validation\n\n- [**EIP-3540**](https://eips.ethereum.org/EIPS/eip-3540): The base EOF V1 spec. Defines the container, header, and the \"tangible benefit\" of code/data separation.\n\n- [**EIP-3670**](https://eips.ethereum.org/EIPS/eip-3670): Mandates code validation at creation time, ensuring no invalid opcodes are deployed.\n\n- [**EIP-5450**](https://eips.ethereum.org/EIPS/eip-5450): Introduces Stack Validation to prevent runtime stack errors.\n\n### Control Flow and Subroutines\n\n- [**EIP-4200**](https://eips.ethereum.org/EIPS/eip-4200): Static Relative Jumps. Adds `RJUMP`, `RJUMPI`, and `RJUMPV` using signed immediate offsets, removing the need for dynamic `JUMP` and `JUMPDEST`.\n\n- [**EIP-4750**](https://eips.ethereum.org/EIPS/eip-4750): EOF Functions. Supports multiple code sections and introduces `CALLF`/`RETF` for intra-contract function calls. It also adds a type section listing inputs/outputs for each function.\n\n- [**EIP-6206**](https://eips.ethereum.org/EIPS/eip-6206): Adds `JUMPF` (opcode `0xE5`) for tail-call jumps and allows marking functions as non-returning (output `0x80`) for optimizations.\n\n### Modernized Instructions\n\n- [**EIP-7480**](https://eips.ethereum.org/EIPS/eip-7480): Data Section Access. Defines `DATALOAD`, `DATALOADN`, `DATASIZE`, and `DATACOPY` to safely access data. Legacy `CODECOPY` is deprecated in EOF.\n\n- [**EIP-663**](https://eips.ethereum.org/EIPS/eip-663): Unlimited Stack Access. Adds `SWAPN`, `DUPN`, and `EXCHANGE`, allowing compilers to access up to 256+ items on the 1024-item stack.\n\n- [**EIP-7069**](https://eips.ethereum.org/EIPS/eip-7069): Revamped CALLs. Replaces legacy `CALL`/`DELEGATECALL` with `EXTCALL`, `EXTDELEGATECALL`, and `EXTSTATICCALL` (removing the gas argument and using the 63/64 rule).\n\n- [**EIP-5920**](https://eips.ethereum.org/EIPS/eip-5920): Introduces the `PAY` opcode (`0xFC`), allowing ETH transfers without invoking the recipient's code, mitigating reentrancy risks.\n\n- [**EIP-7761**](https://eips.ethereum.org/EIPS/eip-7761) & [**EIP-7880**](https://eips.ethereum.org/EIPS/eip-7880): Adds `EXTCODETYPE` to check account types (EOA vs. EOF) and `EXTCODEADDRESS` to resolve EIP-7702 delegations.\n\n### Contract Creation & Metadata\n\n- [**EIP-7620**](https://eips.ethereum.org/EIPS/eip-7620): Replaces `CREATE`/`CREATE2` with `EOFCREATE` and `RETURNCODE`.\n\n- [**EIP-7873**](https://eips.ethereum.org/EIPS/eip-7873): Replaces the former EIP-7698. Defines the `TXCREATE` opcode and InitcodeTransaction for direct EOF deployment from EOAs.\n\n- [**EIP-7834**](https://eips.ethereum.org/EIPS/eip-7834): Adds a separate Metadata Section (kind `0x05`) that is unreachable by code, perfect for CBOR metadata or IPFS hashes without shifting code offsets.\n\n---\n\n## Differences from Legacy EVM Bytecode\n\n| Feature | Legacy EVM | EOF |\n|---|---|---|\n| Container Structure | Unstructured bytecode | Clearly defined sections (Types, Code, Data) |\n| Code Validation | Limited, runtime | Comprehensive, pre-execution (Deploy-time) |\n| Jump Mechanics | Dynamic: `JUMP` / `JUMPI` | Static Relative Jumps: `RJUMP` / `RJUMPI` |\n| Stack Validation | Runtime checks only | Static validation (No underflow/overflow) |\n| Typing | None | Function signatures and typing |\n| Data Handling | Mixed with code | Separate data section (`DATALOAD`) |\n| Introspection | `CODECOPY`, `EXTCODESIZE` | Deprecated; replaced by safer alternatives |\n\n---\n\n## Current Status\n\nEOF was formally removed from the Fusaka hard fork on April 28, 2025, during the [Interop Testing #34 call](https://ethereum-magicians.org/t/interop-testing-34-april-28-2025/23822/2). The decision was confirmed by Tim Beiko in a [GitHub PR updating EIP-7607](https://github.com/ethereum/EIPs/pull/9703).\n\nThe main reasons cited for removal were:\n\n- **Complexity:** Critics, including developer Pascal Caversaccio in a [March 2025 Ethereum Magicians post](https://ethereum-magicians.org/t/evm-object-format-eof/5727), argued EOF introduces too many simultaneous changes , new semantics, over a dozen opcode additions and removals and that its benefits could be achieved through smaller, more targeted updates instead.\n- **Maintenance burden:** Shipping EOF would require maintaining both legacy EVM and EOF contracts indefinitely, increasing long-term complexity for client teams.\n- **Process failures:** Beiko acknowledged in the removal PR that the ACD process failed to adequately resolve community objections across multiple upgrade cycles, despite core devs repeatedly agreeing to ship it.\n- **Timeline risk:** With PeerDAS being the primary Fusaka priority, the ongoing spec debate around EOF variants was seen as a risk to the overall upgrade schedule.\n\nEOF's champions were left open to present a case for inclusion in the subsequent **Glamsterdam** hard fork, but no inclusion has been scheduled as of now. The specification and its constituent EIPs remain available as a historical reference.\n\n---\n\n## Resources\n\n- [**EVM | Pawel Bylica | Lecture 17**](https://www.youtube.com/watch?v=gYnx_YQS8cM) — Detailed technical deep dive into EOF internals and design decisions.\n\n- [**Ethereum Magicians: EVM Object Format (EOF)**](https://ethereum-magicians.org/t/evm-object-format-eof/5727) — The original EIP discussion thread where EOF was proposed and debated by core developers.\n\n- [**Ethereum Notes: EOF**](https://notes.ethereum.org/t-1tLFnLSKCtLZpb-Rw0IA) — Community notes and working documents on the EOF specification and open design questions.\n" }, { "path": "docs/wiki/EL/evm.md", "content": "# The Ethereum Virtual Machine (EVM)\n\nThe Ethereum Virtual Machine (EVM) is the heart of the Ethereum World Computer. It performs the crucial computations needed to finalise transactions, permanently storing the results on the blockchain. This article explores the EVM's role in the Ethereum ecosystem and how it works.\n\n## The Ethereum state machine\n\nAs the EVM processes transactions, it alters the overall state of Ethereum. In that regard, Ethereum can be viewed as a **state machine**.\n\nIn computer science, **state machine** is an abstraction used to model the behavior of a system. It illustrates how a system can be represented by a set of distinct states and how inputs can drive changes in the state.\n\nA familiar example is a vending machine, an automated system for dispensing products upon receiving payment.\n\nWe can model a vending machine existing in three distinct states: idle, awaiting user selection, and dispensing a product. Inputs such as coin insertion or product selection trigger transitions between these states, as depicted in the state diagram:\n\n![Vending machine](../../images/evm/vending-machine.gif)\n\nLet's formally define the components of a state machine:\n\n1. **State ($S$)**: A State represents distinct conditions or configurations that a system can be in at a given point in time.\n For the vending machine, possible states are:\n\n$$ S\\in \\set {Idle, Selection, Dispensing} $$\n\n2. **Inputs ($I$)**: Inputs are actions, signals, or changes in the system's environment. Input triggers the **state transition function**.\n For the vending machine, possible inputs include:\n\n$$ I\\in \\set {InsertCoin, SelectDrink, CollectDrink} $$\n\n3. **State transition function ($\\Upsilon$)**: State transition function defines how the system transitions from one state to another (or back to the same state) based on an input and its current state. Essentially, it determines how the system evolves in response to inputs.\n\n$$\\Upsilon (S,I) \\Longrightarrow S' $$\n\n> Where S' = next state, S= current state, and I= input.\n\nExample state transition for the vending machine:\n\n$$\\Upsilon (Idle,InsertCoin) \\Longrightarrow Selection $$\n$$\\Upsilon (Selection,SelectDrink) \\Longrightarrow Dispensing $$\n$$\\Upsilon (Idle,SelectDrink) \\Longrightarrow Idle $$\n\nNotice in the last case, the current state transitions back to itself.\n\n### Ethereum as a state machine\n\nEthereum, as a whole, can be viewed as a **transaction-based state machine**. It receives transactions as input and transitions into a new state. The current state of Ethereum is referred to as the **world state**.\n\nConsider a simple Ethereum application - an [NFT](https://ethereum.org/en/nft/) marketplace.\n\nIn the current world state **S3** (green), Alice owns an NFT. The animation below shows a transaction transferring ownership to you (**S3** ➡️ **S4**). Similarly, selling the NFT back to Alice would transition the state to **S5**:\n\n![Ethereum state machine](../../images/evm/ethereum-state-machine.gif)\n\nNotice the current world state is animated _as a pulsating green bubble_.\n\nIn the figure above, each transaction is committed to a new state. However, in reality, a group of transactions is bundled into a **block**, and the resulting state is added to the chain of previous states. It must be apparent now why this technology is called **blockchain**.\n\nConsidering the definition of the state transition function, we draw the following conclusion:\n\n> ℹ️ Note\n> **EVM is the state transition function of the Ethereum state machine. It determines how Ethereum transitions into a new (world) state based on input (transactions) and current state.**\n\nIn Ethereum, the world state is essentially a mapping of 20-byte addresses to account states.\n\n![Ethereum world state](../../images/evm/ethereum-world-state.jpg)\n\nEach account state consists of various components such as storage, code, balance among other data and is associated with a specific address.\n\nEthereum has two kinds of accounts:\n\n- **External account:** An account [controlled by an associated private key](/wiki/Cryptography/ecdsa.md) and empty EVM code.\n- **Contract account:** An account controlled by an associated non-empty EVM code. The EVM code as part of such an account is colloquially known as a _smart contract._\n\nRefer [Ethereum data structures](wiki/EL/data-structures.md) for details on how the world state is implemented.\n\n## Virtual machine paradigm\n\nGiven our grasp of state machines, the next challenge is **implementation**.\n\nSoftware needs conversion to the target processor's machine language (Instruction Set Architecture, ISA) for execution. This ISA varies across hardware (e.g., Intel vs. Apple silicon). Modern software also relies on the host operating system for memory management and other essentials.\n\nEnsuring functionality within a fragmented ecosystem of diverse hardware and operating systems is a major hurdle. Traditionally, software had to be compiled into native binaries for each specific target platform:\n\n![Platform dependent execution](../../images/evm/platform-dependent-execution.jpg)\n\nTo address this challenge, a two-part solution is employed.\n\nFirst, the implementation targets a **virtual machine**, an abstraction layer. Source code is compiled into **bytecode**, a sequence of bytes representing instructions. Each bytecode maps to a specific operation the virtual machine executes.\n\nThe second part involves a platform-specific virtual machine that translates the bytecode into native code for execution.\n\nThis offers two key benefits: portability (bytecode runs on different platforms without recompiling) and abstraction (separates hardware complexities from software). Developers can thus write code for a single, virtual machine:\n\n![Virtual machine paradigm](../../images/evm/virtual-machine-paradigm.jpg)\n\n[JVM](https://en.wikipedia.org/wiki/Java_virtual_machine) for Java and LuaVM for Lua are popular examples of Virtual machines. They create platform-neutral bytecode, enabling code to run on various systems without recompiling.\n\n## EVM\n\nThe virtual machine concept serves as an abstraction. Ethereum Virtual Machine (EVM) is a _specific_ software implementation of this abstraction. The anatomy of the EVM is described below:\n\nIn computer architecture, a word refers to a fixed-size unit of data that the CPU can process at once. EVM has a word size of **32 bytes**.\n\n![EVM anatomy](../../images/evm/evm-anatomy.jpg)\n\n_For clarity, the figure above simplifies the Ethereum state. The actual state includes additional elements like Message Frames and Transient Storage._\n\nIn the anatomy described above, EVM is shown to be manipulating the storage, code, and balance of an account instance.\n\nIn a real-world scenario, EVM may execute transactions involving multiple accounts (each with independent storage, code, and balance) enabling complex interactions on Ethereum.\n\nWith a better grasp of virtual machines, let's extend our definition:\n\n> ℹ️ Note\n> EVM is the state transition function of the Ethereum state machine. It determines how Ethereum transitions into a new (world) state based on\n> input (transactions) and current state. **It is implemented as a virtual machine so that it can run on any platform, independent of the\n> underlying hardware.**\n\n## EVM bytecode\n\nEVM bytecode is a representation of a program as a sequence of [**bytes** (8 bits).](https://en.wikipedia.org/wiki/Byte) Each byte within the bytecode is either:\n\n- an instruction known as **opcode**, or\n- input to an opcode known as **operand**.\n\n![Binary bytecode](../../images/evm/opcode-binary.jpg)\n\nFor brevity, EVM bytecode is commonly expressed in [**hexadecimal**](https://en.wikipedia.org/wiki/Hexadecimal) notation:\n\n![Hexadecimal bytecode](../../images/evm/opcode-hex.jpg)\n\nTo further enhance comprehension, opcodes have human-readable mnemonics. This simplified bytecode, called **EVM assembly**, is the lowest human-readable form of EVM code:\n\n![EVM Assembly](../../images/evm/opcode-assembly.jpg)\n\nIdentifying opcodes from operands is straightforward. Currently, only `PUSH*` opcodes have operands (this might change with [EOF](https://eips.ethereum.org/EIPS/eip-7569)). `PUSHX` defines operand length (X bytes after PUSH).\n\nSelect Opcodes used in this discussion:\n\n| Opcode | Name | Description |\n| ------ | -------------- | -------------------------------------------------- |\n| 60 | `PUSH1` | Push 1 byte on the stack |\n| 01 | `ADD` | Add the top 2 values of the stack |\n| 02 | `MUL` | Multiply the top 2 values of the stack |\n| 39 | `CODECOPY` | Copy code running in current environment to memory |\n| 51 | `MLOAD` | Load word from memory |\n| 52 | `MSTORE` | Store word to memory |\n| 53 | `MSTORE8` | Store byte to memory |\n| 59 | `MSIZE` | Get the byte size of the expanded memory |\n| 54 | `SLOAD` | Load word from storage |\n| 55 | `SSTORE` | Store word to storage |\n| 56 | `JUMP` | Alter the program counter |\n| 5B | `JUMPDEST` | Mark destination for jumps |\n| f3 | `RETURN` | Halt execution returning output data |\n| 35 | `CALLDATALOAD` | Copy 32 bytes from calldata to stack |\n| 37 | `CALLDATACOPY` | Copy input data from calldata to memory |\n| 80–8F | `DUP1–DUP16` | Duplicate Nth stack item to top |\n| 90–9F | `SWAP1–SWAP16` | Swap top with N+1th stack item |\n\nRefer [Appendix H of Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf) for a comprehensive list.\n\n> ℹ️ Note\n> [EIPs](https://eips.ethereum.org/) can propose EVM modifications. For instance, [EIP-1153](https://eips.ethereum.org/EIPS/eip-1153) introduced `TSTORE`, and `TSTORE` opcodes.\n\nEthereum clients such as [geth](https://github.com/ethereum/go-ethereum) implement the [EVM specifications](https://github.com/ethereum/execution-specs). This ensures all nodes agree on how transactions alter the system's state, creating a uniform execution environment across the network.\n\nWe have covered **what** EVM is, let's explore **how** it works.\n\n# EVM Data Locations\n\nThe EVM has four main places to store data during execution:\n\n- **Stack**\n- **Memory**\n- **Storage**\n- **Calldata**\n\nLet's explore each of these data stores more in depth.\n\n## Stack\n\nStack is a simple data structure with two operations: **PUSH** and **POP**. Push adds an item to top of the stack, while pop removes the top-most item. Stack operates on Last-In-First-Out (LIFO) principle - the last element added is the first removed. If you try to pop from an empty stack, a **stack underflow error** occurs.\n\nSince the stack is where most opcodes operate, it is responsible for holding the values used to read from and write to **memory** and **storage**, which we'll detail later.\n\nThe primary utility of the stack by the EVM is to store intermediate values in computations and to supply arguments to opcodes.\n\n![EVM stack](../../images/evm/stack.gif)\n\n> The EVM stack has a maximum size of 1024 items consisting of 32 bytes each and is reset after each contract execution. Only the top 16 items are accessible. If you run out of stack, the contract execution will fail.\n\nThe reason behind this 16 item stack size is due to the **DUP** and **SWAP** opcodes.\n\n- **`DUPn`**: Duplicate nth stack item to top.\n- **`SWAPn`**: Swap top with n+1th stack item.\n\nThe maximum n for **DUP** and **SWAP** is `16`, corresponding to opcodes 0x80–0x8f and 0x90–0x9f respectively. These opcodes are explicitly defined in the EVM and form a fixed set — making the 16-item limit an EVM-level constraint.\n\nDuring bytecode execution, EVM stack functions as a _scratchpad_: opcodes consume data from the top and push results back (See the `ADD` opcode below). Consider a simple addition program:\n\n![EVM stack addition](../../images/evm/stack-addition.gif)\n\nReminder: All values are in hexadecimal, so `0x06 + 0x07 = 0x0d (decimal: 13)`.\n\nLet's take a moment to celebrate our first EVM assembly code 🎉.\n\n### Program counter\n\nRecall that the bytecode is a flat array of bytes with each opcode being a 1 byte. The EVM needs a way to track what is the next byte (opcode) to execute in the bytecode array. This is where the EVM **program counter** comes in. It will keep track of the next opcode's offset, which is the location in the byte array of the next instruction to execute on the stack.\n\nIn the example above, the values on the left of the assembly code represent the byte offset (starting at 0) of each opcode within the bytecode:\n\n| Bytecode | Assembly | Length of Instruction in bytes | Offset in hex |\n| -------- | -------- | ------------------------------ | ------------- |\n| 60 06 | PUSH1 06 | 2 | 00 |\n| 60 07 | PUSH1 07 | 2 | 02 |\n| 01 | ADD | 1 | 04 |\n\nNotice how the table above doesn't include offset 01. This is because the operand 06 takes position of offset 01, and the same concept applies for operand 07 taking position of offset 03.\n\nEssentially, the **program counter** ensures the EVM knows the position of each next instruction to execute and when to stop executing as illustrated in the example below.\n\n![EVM program counter](../../images/evm/program-counter.gif)\n\nThe `JUMP` opcode directly sets the program counter, enabling dynamic control flow and contributing to the EVM's [Turing completeness](https://en.wikipedia.org/wiki/Turing_completeness) by allowing flexible program execution paths.\n\n![EVM JUMP opcode](../../images/evm/jump-opcode.gif)\n\nThe code runs in an infinite loop, repeatedly adding 7. It introduces two new opcodes:\n\n- **JUMP**: Sets the program counter to stack top value (02 in our case), determining the next instruction to execute.\n- **JUMPDEST**: Marks the destination of a jump operation, ensuring intended destinations and preventing unwanted control flow disruptions.\n\n> High level languages like [Solidity](https://soliditylang.org/) leverage jumps for constructs like if conditions, for loops, and internal functions calls.\n\n### Gas\n\nOur innocent little program may seem harmless. However, infinite loops in EVM pose a significant threat: they can **devour resources**, potentially causing network [**DoS attacks**.](https://en.wikipedia.org/wiki/Denial-of-service_attack)\n\nThe EVM's **gas** mechanism tackles such threats by acting as a currency for computational resources. Gas costs are [designed to mirror](https://web.archive.org/web/20170904200443/https://docs.google.com/spreadsheets/d/15wghZr-Z6sRSMdmRmhls9dVXTOpxKy8Y64oy9MvDZEQ/edit#gid=0) the limitations of hardware, such as storage capacity or processing power. Transactions pay gas in **Ether (ETH)** to use the EVM, and if they run out of gas before finishing (like an infinite loop), the EVM halts them to prevent resource hogging.\n\nThis protects the network from getting clogged by resource-intensive or malicious activities. Since gas restricts computations to a finite number of steps, the EVM is considered **quasi Turing complete**.\n\n![EVM Gas](../../images/evm/evm-gas.gif)\n\nOur example assumed 1 unit of gas per opcode for simplicity, but the actual cost varies based on complexity. The core concept, however, remains unchanged.\n\nRefer [Appendix G of Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf) for specific gas costs.\n\n## Memory\n\nEVM memory is a byte array of $2^{256}$ (or [practically infinite](https://www.talkcrypto.org/blog/2019/04/08/all-you-need-to-know-about-2256/)) bytes. All locations in memory are well-defined initially as zero.\n\n![EVM Memory](../../images/evm/evm-memory.gif)\n\nUnlike stack, which provides data to individual instructions, memory stores ephemeral data that is relevant to the entire program. Since the stack has a hard limit of one word slots, **memory** supplements the stack by allowing indexed access to arbitrarily sized data. Stack values can be stored to or loaded from **memory** on demand.\n\n### Writing to memory\n\n`MSTORE` takes two values from the stack: an address **offset** and a 32-byte **value**. It then writes the value to memory at the specified offset.\n\n![MSTORE](../../images/evm/mstore.gif)\n\n`MSIZE` reports currently used memory size (in bytes) on the stack (32 bytes or 20 hex in this case).\n\n`MSTORE8` takes same arguments as `MSTORE`, but writes 1 byte instead of 1 word.\n\n![MSTORE8](../../images/evm/mstore8.gif)\n\nNotice: When writing 07 to memory, the existing value (06) remains unchanged. It's written to the adjacent byte offset.\n\nThe size of active memory is still 1 word.\n\n### Memory expansion\n\nIn EVM, memory is dynamically allocated in multiples of 1 word “pages”. Gas is charged for the number of pages expanded.\n\n![Memory expansion](../../images/evm/memory-expansion.gif)\n\nWriting a word at a 1-byte offset overflows the initial memory page, triggering an expansion to 2 words (64 bytes or 0x40).\n\n### Reading from memory\n\n`MLOAD` reads a value from memory and pushes it onto the stack.\n\n![MLOAD](../../images/evm/mload.gif)\n\nEVM doesn't have a direct equivalent to `MSTORE8` for reading. You must read the entire word using `MLOAD` and then extract the desired byte using a [mask]().\n\n> EVM memory is shown as blocks of 32 bytes to illustrate how memory expansion works. In reality, it is a seamless sequence of bytes, without any inherent divisions or blocks.\n\n## Calldata\n\nThe **calldata** is read-only input data passed to the EVM via message call instructions or from a transaction and is stored as a sequence of bytes that are accessible via specific opcodes.\n\n### Reading from calldata\n\nThe calldata for the current environment can be accessed using either:\n\n- `CALLDATALOAD` opcode which reads 32 bytes from a desired offset onto the stack, [learn more](https://veridelisi.medium.com/learn-evm-opcodes-v-a59dc7cbf9c9).\n- or, using `CALLDATACOPY` to copy a portion of calldata to memory.\n\n## Storage\n\nStorage is designed as a **word-addressed word array**. Unlike memory, storage is associated with an Ethereum account and is **persisted** across transactions as part of the world state. It can be thought of as a key-value **database** associated with the smart contract, which is why it contains the contract's \"state\" variables. Storage size is fixed at 2^256 slots, 32 bytes each.\n\n![EVM Storage](../../images/evm/evm-storage.jpg)\n\nStorage can only be accessed via the code of its associated account. External accounts don't have code and therefore cannot access their own storage.\n\n## Writing to storage\n\n`SSTORE` takes two values from the stack: a storage **slot** and a 32-byte **value**. It then writes the value to storage of the account. Notice: Slots can be thought of as the basic unit of storage, so when writing to storage, we deal with slots as opposed to individual bytes. Writing to storage is expensive. High-level languages like Solidity optimize storage by packing multiple variables into a single 32-byte slot when their combined size is less than or equal to 32 bytes.\n\n![EVM Storage write](../../images/evm/sstore.gif)\n\nWe've been running a contract account's bytecode all this time. Only now we see the account and the world state, and it matches the code inside the EVM.\n\nAgain, it’s important to note that storage is not part of the EVM itself, rather the currently executing contract account. More specifically, the contract account contains a **storage root** that points to a separate Merkle Patricia Trie for that contract's storage.\n\nThe example above shows only a small section of the account's storage. Like memory, all the values in storage are well-defined as zero. Also, when a contract executes an `SSTORE` opcode that sets a storage slot’s value from non-zero back to zero, the operation becomes eligible for a gas refund (the gas is not returned immediately but is credited to the transaction’s refund counter)​. This refund serves as a reward to accounts for freeing up valuable storage from the state trie and is applied at the end of the transaction to offset some of the gas cost. \n\n\n### Reading from storage\n\n`SLOAD` takes the storage **slot** from the stack and loads its value back onto it.\n\n![EVM Storage read](../../images/evm/sload.gif)\n\nNotice that the storage value persists between examples, demonstrating its persistence within the world state. Since the world state is replicated across all nodes, storage operations are gas expensive.\n\n> ℹ️ Note\n> Check out the wiki on [transaction](/wiki/EL/transaction.md) to see EVM in action.\n\n## Wrapping up\n\nWe've explored how opcodes are the core instructions executed by the EVM, operating on the stack to perform computations. Computed results can be stored ephemerally in memory or persisted in contract storage.\n\nDevelopers rarely write EVM assembly code directly unless performance optimization is crucial. Instead, most developers work with higher-level languages like [Solidity](https://soliditylang.org/), which is then compiled into bytecode.\n\nEthereum is a continuously evolving protocol and while the fundamentals we've discussed will remain largely relevant, following [Ethereum Improvement Proposals (EIPs)](https://eips.ethereum.org/) and [network upgrades](https://ethereum.org/history) is encouraged to stay informed of the latest developments in the Ethereum ecosystem.\n\n## EVM upgrades\n\nWhile Ethereum protocol undergoes many changes in each upgrade, changes in EVM are rather subtle. Major change in EVM might break contracts and languages, requiring keeping multiple versions of EVM which introduces a lot of complexity overhead. There are still certain upgrades done on EVM itself like new opcodes or changes to existing ones which don't break their logic. Some examples are EIPs like [1153](https://eips.ethereum.org/EIPS/eip-1153), [4788](https://eips.ethereum.org/EIPS/eip-4788), [5000](https://eips.ethereum.org/EIPS/eip-5000), [5656](https://eips.ethereum.org/EIPS/eip-5656) and [6780](https://eips.ethereum.org/EIPS/eip-6780). These are proposing to add new opcodes except the last one which is especially interesting because it's neutralizing `SELFDESTRUCT` opcode without breaking compatibility. Another important upgrade to EVM which would mark rather a major change is [EOF](https://notes.ethereum.org/@ipsilon/mega-eof-specification). It creates a format to bytecode which EVM can understand and process more easily, it encompasses various EIPs and has been discussed and polished for quite some time.\n\n## Resources\n\n### State machines and theory of computation\n\n- 📝 Mark Shead, [\"Understanding State Machines.\"](https://medium.com/free-code-camp/state-machines-basics-of-computer-science-d42855debc66) • [archived](https://web.archive.org/web/20210309014946/https://medium.com/free-code-camp/state-machines-basics-of-computer-science-d42855debc66)\n- 🎥 Prof. Harry Porter, [\"Theory of computation.\"](https://www.youtube.com/playlist?list=PLbtzT1TYeoMjNOGEiaRmm_vMIwUAidnQz)\n- 📘 Michael Sipser, [\"Introduction to the Theory of Computation.\"](https://books.google.com/books/about/Introduction_to_the_Theory_of_Computatio.html?id=4J1ZMAEACAAJ)\n- 🎥 Shimon Schocken et al., [\"Build a Modern Computer from First Principles: From Nand to Tetris.\"](https://www.coursera.org/learn/build-a-computer)\n\n### EVM\n\nThe resources below has been categorized into different sections based on different EVM learning stages.\n\n#### Basics of EVM\n\n- 🎥 Whiteboard Crypto, [\"EVM: An animated non-technical introduction.\"](https://youtu.be/sTOcqS4msoU)\n- 📝 Vasa, [Getting Deep Into EVM: How Ethereum Works Backstage](https://medium.com/swlh/getting-deep-into-evm-how-ethereum-works-backstage-ab6ad9c0d0bf)\n- 📝 Zaryab Afser, [The ABCs of Ethereum Virtual Machine](https://www.decipherclub.com/the-abcs-of-ethereum-virtual-machine/)\n- 📝 Preethi, [EVM Tweet Thread](https://twitter.com/iam_preethi/status/1483459717670309895)\n- 📝 Decipher Club, [EVM learning resources based on your level of expertise](https://www.decipherclub.com/evm-learning-resources/)\n\n#### Understanding EVM Architecture & Core Components\n\n- 📝 Gavin Wood, [\"Ethereum Yellow Paper.\"](https://ethereum.github.io/yellowpaper/paper.pdf)\n- 📝 Ethereum Book, [Chapter 13, Ethereum Book](https://cypherpunks-core.github.io/ethereumbook/13evm.html?ref=decipherclub.com)\n- 📘 Andreas M. Antonopoulos & Gavin Wood, [\"Mastering Ethereum.\"](https://github.com/ethereumbook/ethereumbook)\n- 🎥 Jordan McKinney, [\"Ethereum Explained: The EVM.\"](https://www.youtube.com/watch?v=kCswGz9naZg)\n- 📝 LeftAsExercise, [\"Smart contracts and the Ethereum virtual machine.\"](https://leftasexercise.com/2021/08/08/q-smart-contracts-and-the-ethereum-virtual-machine/) • [archived](https://web.archive.org/web/20230324200211/https://leftasexercise.com/2021/08/08/q-smart-contracts-and-the-ethereum-virtual-machine/)\n- 📝 Femboy Capital, [\"A Playdate with the EVM.\"](https://femboy.capital/evm-pt1) • [archived](https://web.archive.org/web/20221001113802/https://femboy.capital/evm-pt1)\n- 🎥 Alex, [EVM - Some Assembly Required](https://www.youtube.com/watch?v=yxgU80jdwL0)\n\n#### Deep-Dive into EVM\n\n- 📝 Takenobu Tani, [EVM illustrated](https://github.com/takenobu-hs/ethereum-evm-illustrated)\n- 📝 Shafu, [\"EVM from scratch.\"](https://evm-from-scratch.xyz/)\n- 📝 NOXX, [\"3 part series: EVM Deep Dives - The Path to Shadowy Super Coder.\"](https://noxx.substack.com/p/evm-deep-dives-the-path-to-shadowy) • [archived](https://web.archive.org/web/20240106034644/https://noxx.substack.com/p/evm-deep-dives-the-path-to-shadowy)\n- 📝 OpenZeppelin, [\"6 part series: Deconstructing a Solidity.\"](https://blog.openzeppelin.com/deconstructing-a-solidity-contract-part-i-introduction-832efd2d7737) • [archived](https://web.archive.org/web/20240121025651/https://blog.openzeppelin.com/deconstructing-a-solidity-contract-part-i-introduction-832efd2d7737)\n- 📝 TrustLook, [\"Understand EVM bytecode.\"](https://blog.trustlook.com/understand-evm-bytecode-part-1/) • [archived](https://web.archive.org/web/20230603080857/https://blog.trustlook.com/understand-evm-bytecode-part-1/)\n- 📝 Degatchi, [\"A Low-Level Guide To Solidity's Storage Management.\"](https://degatchi.com/articles/low_level_guide_to_soliditys_storage_management) • [archived](https://web.archive.org/web/20231202105650/https://degatchi.com/articles/low_level_guide_to_soliditys_storage_management/)\n- 📝 Zaryab Afser, [\"Journey of smart contracts from Solidity to Bytecode\"](https://www.decipherclub.com/ethereum-virtual-machine-article-series/)\n- 🎥 Ethereum Engineering Group, [EVM: From Solidity to byte code, memory and storage](https://www.youtube.com/watch?v=RxL_1AfV7N4&t=2s)\n- 📝 Trust Chain, [7 part series about how Solidity uses EVM under the hood.](https://trustchain.medium.com/reversing-and-debugging-evm-smart-contracts-392fdadef32d)\n- [Learn EVM Opcodes](https://veridelisi.medium.com/learn-evm-opcodes-v-a59dc7cbf9c9) • [archived](https://web.archive.org/web/20240806231824/https://veridelisi.medium.com/learn-evm-opcodes-v-a59dc7cbf9c9)\n- [More on EVM Storage](https://medium.com/coinmonks/solidity-storage-how-does-it-work-8354afde3eb) • [archived](https://web.archive.org/web/20230808231549/https://medium.com/coinmonks/solidity-storage-how-does-it-work-8354afde3eb)\n- [Storage, Memory, and Stack Overview](https://ethereum.stackexchange.com/questions/23720/usage-of-memory-storage-and-stack-areas-in-evm) • [archived](https://web.archive.org/web/20240529150647/https://ethereum.stackexchange.com/questions/23720/usage-of-memory-storage-and-stack-areas-in-evm)\n- [Calldata](https://learnevm.com/chapters/fn/calldata) • [archived](https://web.archive.org/web/20250306133755/https://learnevm.com/chapters/fn/calldata)\n\n### Tools & EVM Puzzles\n\n- 🧮 smlXL, [\"evm.codes: Opcode reference and interactive playground.\"](https://www.evm.codes/)\n- 🧮 smlXL, [\"evm.storage: Interactive storage explorer.\"](https://www.evm.storage/)\n- 🧮 Ethervm, [Low level reference for EVM opcodes](https://ethervm.io/)\n- 🎥 Austin Griffith, [\"ETH.BUILD.\"](https://www.youtube.com/watch?v=30pa790tIIA&list=PLJz1HruEnenCXH7KW7wBCEBnBLOVkiqIi)\n- 💻 Franco Victorio, [\"EVM puzzles.\"](https://github.com/fvictorio/evm-puzzles)\n- 💻 Dalton Sweeney, [\"More EVM puzzles.\"](https://github.com/daltyboy11/more-evm-puzzles)\n- 💻 Zaryab Afser, [\"Decipher EVM puzzles.\"](https://www.decipherclub.com/decipher-evm-puzzles-game/)\n\n## Implementations\n\n- 💻 Solidity: Brock Elmore, [\"solvm: EVM implemented in solidity.\"](https://github.com/brockelmore/solvm)\n- 💻 Go: [Geth](https://github.com/ethereum/go-ethereum)\n- 💻 C++: [EVMONE](https://github.com/ethereum/evmone)\n- 💻 Python: [py-evm](https://github.com/ethereum/py-evm)\n- 💻 Rust: [revm](https://github.com/bluealloy/revm)\n- 💻 Js/CSS: Riley, [\"The Ethereum Virtual Machine.\"](https://github.com/jtriley-eth/the-ethereum-virtual-machine)\n\n### EVM based programming languages\n\n- 🗄 [Solidity](https://soliditylang.org/)\n- 🗄 [Huff](https://github.com/huff-language/)\n- 🗄 [Vyper](https://docs.vyperlang.org/en/stable/)\n- 🗄 [Fe](https://fe-lang.org/)\n" }, { "path": "docs/wiki/EL/precompiled-contracts.md", "content": "# Precompiled contracts\n\nPrecompiled contracts are a set of special accounts, each containing a built-in function with a determined gas cost, often related to complex cryptographic computations. Currently, they are defined at addresses ranging from `0x01` to `0x0a`.\n\nUnlike contract accounts, precompiles are part of the Ethereum protocol and implemented by [execution clients](/wiki/EL/el-clients.md). This presents an interesting caveat - their `EXTCODESIZE` within EVM is 0. Nonetheless, they function like contract accounts with code when executed.\n\nPrecompiles are included in the initial `\"accessed_addresses\"` of a transaction as defined by [EIP-2929](https://eips.ethereum.org/EIPS/eip-2929) to save gas costs.\n\n## Precompiles vs. opcodes\n\nBoth precompiles and opcodes have the same goal of performing arbitrary computations. Following considerations are made when choosing between them:\n\n- **Limited opcode space**: The EVM opcode space of 1-byte is inherently constrained (256 opcodes, `0x00`-`0xFF`). This necessitates judicious allocation for essential operations.\n- **Efficiency**: Precompiled contracts are natively executed outside the EVM, enabling efficient implementations for complex cryptographic computations that power many cross-chain interactions.\n\nQuoting [\"A Prehistory of the Ethereum Protocol\"](https://vitalik.eth.limo/general/2017/09/14/prehistory.html) by Vitalik:\n\n> The second was the idea of \"precompiles\", solving the problem of allowing complex cryptographic computations to be usable in the EVM without having to deal with EVM overhead. We had also gone through many more ambitious ideas about \"native contracts\", where if miners have an optimized implementation of some contracts they could \"vote\" the gasprice of those contracts down, so contracts that most miners could execute much more quickly would naturally have a lower gas price; however, all of these ideas were rejected because we could not come up with a cryptoeconomically safe way to implement such a thing. An attacker could always create a contract which executes some trapdoored cryptographic operation, distribute the trapdoor to themselves and their friends to allow them to execute this contract much faster, then vote the gasprice down and use this to DoS the network. Instead we opted for the much less ambitious approach of having a smaller number of precompiles that are simply specified in the protocol, for common operations such as hashes and signature schemes.\n\n## List of precompiles\n\n| Address | Name | Description | Since |\n| ------- | -------------------- | ------------------------------------------ | ------------------------------------------------------------- |\n| 0x01 | ECRECOVER | Elliptic curve public key recover | Frontier |\n| 0x02 | SHA2-256 | SHA2 256-bit hash scheme | Frontier |\n| 0x03 | RIPEMD-160 | RIPEMD 160-bit hash scheme | Frontier |\n| 0x04 | IDENTITY | Identity function | Frontier |\n| 0x05 | MODEXP | Arbitrary precision modular exponentiation | Byzantium ([EIP-198](https://eips.ethereum.org/EIPS/eip-198)) |\n| 0x06 | ECADD | Elliptic curve addition | Byzantium ([EIP-196](https://eips.ethereum.org/EIPS/eip-196)) |\n| 0x07 | ECMUL | Elliptic curve scalar multiplication | Byzantium ([EIP-196](https://eips.ethereum.org/EIPS/eip-196)) |\n| 0x08 | ECPAIRING | Elliptic curve pairing check | Byzantium ([EIP-197](https://eips.ethereum.org/EIPS/eip-197)) |\n| 0x09 | BLAKE2 | BLAKE2 compression function | Istanbul ([EIP-152](https://eips.ethereum.org/EIPS/eip-152)) |\n| 0x0a | KZG POINT EVALUATION | Verifies a KZG proof | Cancun ([EIP-4844](https://eips.ethereum.org/EIPS/eip-4844)) |\n\n## How it works\n\nThe beauty of precompiles lies in design of its interface, which is identical to external smart contract calls, allowing for a familiar interaction - from a developer's perspective, usage of precompile no different than an external call.\n\nGas costs for precompiles are directly tied to the input data – fixed inputs translate to fixed costs. To determine these costs, developers rely on a combination of reference implementations and benchmarks. Benchmarks typically measure execution time on specific hardware, while some, like `MODEXP`, [define consumption directly in terms of gas usage per second](https://eips.ethereum.org/EIPS/eip-2565#1-modify-computational-complexity-formula-to-better-reflect-the-computational-complexity). This meticulous approach aims to prevent denial-of-service attacks by ensuring predictable resource allocation.\n\nUnder the hood, client implementations leverage optimized libraries to execute precompiles. While this approach enhances efficiency, it introduces a potential security risk. If a bug is found within these libraries, it could disrupt the entire protocol layer. To mitigate this risk, rigorous [testing](/wiki/testing/overview.md) is crucial (e.g. [MODEXP test specs](https://github.com/ethereum/execution-spec-tests/tree/main/tests/byzantium/eip198_modexp_precompile)).\n\nTo prevent security vulnerabilities, precompiles are designed to avoid nested calls.\n\n## Calling precompiles\n\nLike contract account, precompiles can be called using `*CALL` family of opcodes. The following assembly code example shows usage of `SHA-256` precompile to hash the string \"Hello\":\n\n```js\n// First place the parameters in memory\nPUSH5 0x48656C6C6F // Hello in UTF-8\nPUSH1 0\nMSTORE\n\n// Call SHA-256 precompile (0x02)\nPUSH1 0x20 // retSize\nPUSH1 0x20 // retOffset\nPUSH1 5 // argsSize\nPUSH1 0x1B // argsOffset\nPUSH1 2 // address\nPUSH4 0xFFFFFFFF // gas\nSTATICCALL\n\nPOP // Pop the result of the STATICCALL\n\n// LOAD the result from memory to stack\nPUSH1 0x20\nMLOAD\n```\n\nwhich yields the hash:\n\n```\n185f8db32271fe25f561a6fc938b2e264306ec304eda518007d1764826381969\n```\n\n> ▶️ [Try it in the EVM playground!](https://www.evm.codes/playground?fork=cancun&unit=Wei&codeType=Mnemonic&code='~FirsKplaceqparameters%20inYZ5948656C6C6FjHello%20in%20UTF-8w0vMSTOREvv~Call%20SHA-256%20precompilJ%7BV02%7DNSizeNW5QSizewV1BQW2jaddressZ49FFFFFFFFjgasvbPOPjPop_ofqb~LOAD_fromYGo%20stackXvMLOAD'~%2F%2F%20wZ1%20v%5CnqGhJj%20~bSTATICCALLvv_qresulKZvPUSHY%20memoryXwV20WOffsetwV0xQjargsNXjretKt%20Je%20G%20t9%20V%019GJKNQVWXYZ_bjqvw~_)\n\nRefer the wiki on [EVM](/wiki/EL/evm.md) to understand how assembly code works.\n\n## Proposed precompiles\n\n[EIPs](https://eips.ethereum.org/) can introduce new precompiles as part of hard forks. There is general resistance in adding new precompiles as the testing surface and maintenance cost is high. To address this, a proposed approach involves prototyping precompiles on Layer 2 solutions first, and then integrating them into the mainnet only after they demonstrate stability and widespread adoption.\n\n Following precompiles are currently proposed:\n\n- [EIP-2537: Precompile for BLS12-381 curve operations](https://eips.ethereum.org/EIPS/eip-2537)\n- [RIP-7212: Precompile for secp256r1 Curve Support](https://github.com/ethereum/RIPs/blob/master/RIPS/rip-7212.md)\n- [EIP-7545: Verkle proof verification precompile](https://eips.ethereum.org/EIPS/eip-7545)\n- [EIP-5988: Add Poseidon hash function precompile](https://eips.ethereum.org/EIPS/eip-5988)\n\nThe introduction of new precompiles requires careful consideration of their network effects. A precompile with miscalculated gas cost could potentially cause denial of service by consuming more resources than anticipated. Additionally, a growing number of precompiles can lead to code bloat within the EVM clients, increasing the burden on validators.\n\nThe selection of cryptographic functions and their corresponding parameters for precompiles requires a thorough analysis to balance security and efficiency. These parameters are generally preset within the precompile logic as parametrizing these from user input could be a security concern. Moreover, optimizing security functions with a wide range of parameters is difficult for fast execution, which is the fundamental requirement of precompiles.\n\n## Removing precompiles\n\nDiscussions are ongoing regarding potential removal of precompiles that are outdated, underutilized, or hinder client software efficiency. The identity precompile (replaced by the `MCOPY` opcode), `RIPEMD-160`, and BLAKE functions are prime candidates for retirement.\n\nHowever, instead of complete removal,these precompiles could be migrated to efficient smart contract implementations. This approach would ensure continued functionality but with a corresponding increase in gas costs.\n\n## Implementations\n\n- [Besu - `org.hyperledger.besu.evm.precompile` package](https://github.com/hyperledger/besu/tree/3d5f45c35ffce4b5173b2ce5972827f9634317d6/evm/src/main/java/org/hyperledger/besu/evm/precompile)\n- [Geth - `core/vm/contracts.go`](https://github.com/ethereum/go-ethereum/blob/b2b0e1da8cac279bf0466885d1abdc5d93402f41/core/vm/contracts.go)\n- [Nethermind - `Nethermind.EVM.Precompiles` namespace](https://github.com/NethermindEth/nethermind/tree/f3edf2503d2637a37f8b509924e10f88491ddd6e/src/Nethermind/Nethermind.Evm/Precompiles)\n- [Reth - REVM Precompiles crates](https://github.com/bluealloy/revm/tree/1ca3d39f6a9e9778f8eb0fcb74fe529345a531b4/crates/precompile/src)\n\n## Research\n\nA proposed approach called [\"progressive precompiles\"](https://ethereum-magicians.org/t/eip-proposal-create2-contract-factory-precompile-for-deployment-at-consistent-addresses-across-networks/6083/26) aims to improve the deployment process. These precompiles would reside at deterministic CREATE2 addresses, allowing user contracts to interact with the same address regardless of whether the precompile is live on the mainnet or a specific L2. This approach ensures a smoother transition when native client precompiles become available.\n\n## Resources\n\n- [Appendix E: Ethereum Yellow Paper.](https://ethereum.github.io/yellowpaper/paper.pdf)\n- [Week 10: Precompiles overview by Danno Ferrin](/eps/week10-dev.md)\n- [Catalog of EVM Precompile](https://github.com/shemnon/precompiles/)\n- [Go Ethereum Precompile Implementation.](https://github.com/ethereum/go-ethereum/blob/master/core/vm/contracts.go)\n- [A Prehistory of the Ethereum Protocol](https://vitalik.eth.limo/general/2017/09/14/prehistory.html)\n- [Stack Exchange: What's a precompiled contract and how are they different from native opcodes?](https://ethereum.stackexchange.com/questions/440/whats-a-precompiled-contract-and-how-are-they-different-from-native-opcodes)\n- [Stack Exchange: Why aren't more common algorithms done as precompiles?](https://ethereum.stackexchange.com/questions/155787/why-arent-more-common-algorithms-done-as-precompiles)\n- [A call, a precompile and a compiler walk into a bar](https://blog.theredguild.org/a-call-a-precompile-and-a-compiler-walk-into-a-bar/)\n" }, { "path": "docs/wiki/EL/transaction.md", "content": "# Transaction\n\nA **transaction** is a cryptographically-signed instruction issued by **an external account**, submitted to an execution client via [JSON-RPC](/wiki/EL/JSON-RPC.md) and then broadcasted to the entire network using [DevP2p](/wiki/EL/devp2p).\n\nA transaction contains following fields:\n\n- **nonce ($T_n$)**: An integer value equal to the number of transactions sent by the sender. Nonce is used to:\n\n - **Prevent replay attack**: Let's say Alice sends 1 ETH to Bob in a transaction, Bob might try to rebroadcast the same transaction into the network to get additional funds from Alice's account. Since the transaction is signed with a unique nonce, EVM will simply reject it if Bob sends it again. Thus safeguarding Alice's account from unauthorized duplicate transactions.\n - **Determine contract account address**: In `contract creation` mode, nonce along with the sender's address is used to determine the contract account address.\n - **Replace a transaction**: When a transaction gets stuck due to low gas price, miners often allow a replacement transaction that has the same nonce. Some wallets may provide the option to cancel a transaction by exploiting this behavior. Essentially, a new transaction with the same nonce, higher gas price, and 0 value is sent, effectively overshadowing the original pending transaction. However, it's crucial to understand that the success of replacing a pending transaction is not guaranteed, as it relies on the behavior of miners and network conditions.\n\n- **gasPrice ($T_p$)**: An integer value equal to the number wei to be paid per unit of gas. **Wei** is the smallest denomination of ether. $1 \\textnormal{ETH} = 10^{18} \\textnormal{Wei}$. Gas price is used to prioritize the execution of a transaction. Higher the gas price, more likely that a miner will include the transaction as part of a block.\n\n- **gasLimit ($T_g$)**: An integer value equal to the maximum amount of gas to be used in execution of this transaction. Execution of this transaction will stop if the gasLimit is exhausted.\n\n- **to ($T_t$)**: The 20-byte address of the recipient of this transaction. The `to` field also determines the mode or purpose of the transaction:\n\n| Value of `to` | Transaction Mode | Description |\n| ---------------- | ------------------ | --------------------------------------------------------- |\n| _Empty_ | Contract creation | The transaction creates a new contract account. |\n| External Account | Value transfer | The transaction transfers Ether to an external account. |\n| Contract Account | Contract execution | The transaction invokes the existing smart contract code. |\n\n- **value ($T_v$)**: An integer value equal to the number of Wei to be transferred to this transaction's recipient. In `Contract creation` mode, value becomes the initial balance of the newly created contract account.\n\n- **data ($T_d$) or init($T_i$)**: An unlimited size byte array specifying the input to the EVM. In contract `creation mode`, this value is considered as `init bytecode`, otherwise byte array of `input data`.\n\n- **Signature ($T_v, T_r, T_s$)**: [ECDSA](/wiki/Cryptography/ecdsa.md) signature of the sender.\n\n\n## Contract creation\n\nLet's deploy the following code onto a new contract account:\n\n```bash\n[00] PUSH1 06 // Push 06\n[02] PUSH1 07 // Push 07\n[04] MUL // Multiply\n[05] PUSH1 0 // Push 00 (storage address)\n[07] SSTORE // Store result to storage slot 00\n```\n\nThe brackets indicate instruction offset. Corresponding bytecode:\n\n```bash\n6006600702600055\n```\n\nNow, let's prepare the `init` value of our transaction to deploy this bytecode. Init actually consists of two fragments:\n\n```\n \n```\n\n`init` is executed by EVM only once at account creation. The return value of init code execution is the **runtime bytecode**, which is stored as part of the contract account. Runtime bytecode is executed every time a contract account receives a transaction.\n\nLet's prepare our init code such that it returns our runtime code:\n\n```bash\n// 1. Copy to memory\n[00] PUSH1 08 // PUSH1 08 (length of our runtime code)\n[02] PUSH1 0c // PUSH1 0c (offset of the runtime code in init)\n[04] PUSH1 00 // PUSH1 00 (destination in memory)\n[06] CODECOPY // Copy code running in current environment to memory\n// 2. Return from memory\n[07] PUSH1 08 // PUSH1 08 (length of return data)\n[09] PUSH1 00 // PUSH1 00 (memory location to return from)\n[0b] RETURN // Return the runtime code and halt execution\n// 3. Runtime code (8 bytes long)\n[0c] PUSH1 06\n[0e] PUSH1 07\n[10] MUL\n[11] PUSH1 0\n[13] SSTORE\n```\n\nThe code does 2 simple things: First, copy the runtime bytecode to memory and then return the runtime bytecode from memory.\n\n`init` bytecode:\n\n```javascript\n6008600c60003960086000f36006600702600055\n```\n\nNext, prepare the transaction payload:\n\n```javascript\n[\n \"0x\", // nonce (zero nonce, since first transaction)\n \"0x77359400\", // gasPrice (we're paying 2000000000 wei per unit of gas)\n \"0x13880\", // gasLimit (80000 is standard gas for deployment)\n \"0x\", // to address (empty in contract creation mode)\n \"0x05\", //value (we'll be nice and send 5 wei to our new contract)\n \"0x6008600c60003960086000f36006600702600055\", // init code\n];\n```\n\n> Order of the values in the payload is important!\n\nFor this example, we'll use [Foundry](https://getfoundry.sh/) to deploy the transaction locally. Foundry is an ethereum development toolkit that provides following cli tools:\n\n- **Anvil** : A local Ethereum node, designed for development.\n- **Cast**: A tool for performing Ethereum RPC calls.\n\nInstall and launch [anvil](https://book.getfoundry.sh/anvil/) local node.\n\n```\n$ anvil\n\n\n _ _\n (_) | |\n __ _ _ __ __ __ _ | |\n / _` | | '_ \\ \\ \\ / / | | | |\n | (_| | | | | | \\ V / | | | |\n \\__,_| |_| |_| \\_/ |_| |_|\n\n 0.2.0 (5c3b075 2024-03-08T00:17:08.007462509Z)\n https://github.com/foundry-rs/foundry\n\nAvailable Accounts\n==================\n\n(0) \"0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266\" (10000.000000000000000000 ETH)\n.....\n\nPrivate Keys\n==================\n\n(0) 0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80\n.....\nListening on 127.0.0.1:8545\n```\n\nSign the transaction using one of anvil's dummy account:\n\n```bash\n$ node sign.js '[ \"0x\", \"0x77359400\", \"0x13880\", \"0x\", \"0x05\", \"0x6008600c60003960086000f36006600702600055\" ]' ac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80\n\nf864808477359400830138808005946008600c60003960086000f360066007026000551ca01446316c9bdcbe0cb87fac0b08a00e59552634c96d0d6e2bd522ea0db827c1d0a0170680b6c348610ef150c1b443152214203c7f66288ea6332579c0cdfa86cc3f\n```\n\n> See **Appendix A** below for the source of `sign.js` helper script.\n\nFinally, submit the transaction using [cast](https://book.getfoundry.sh/cast/):\n\n```javascript\n$ cast publish f864808477359400830138808005946008600c60003960086000f360066007026000551ca01446316c9bdcbe0cb87fac0b08a00e59552634c96d0d6e2bd522ea0db827c1d0a0170680b6c348610ef150c1b443152214203c7f66288ea6332579c0cdfa86cc3f\n\n{\n \"transactionHash\": \"0xdfaf2817f19963846490b330ae33eba7b42872e8c8bd111c8d7ea3846c84cd51\",\n \"transactionIndex\": \"0x0\",\n \"blockHash\": \"0xfde1475a716583d847f858c5db3e54156983b39e3dbefaa5829416e6e60a788a\",\n \"blockNumber\": \"0x1\",\n \"from\": \"0xf39fd6e51aad88f6f4ce6ab8827279cfffb92266\",\n \"to\": null,\n \"cumulativeGasUsed\": \"0xd67e\",\n \"gasUsed\": \"0xd67e\",\n // Newly created contract address 👇\n \"contractAddress\": \"0x5fbdb2315678afecb367f032d93f642f64180aa3\",\n \"logs\": [],\n \"status\": \"0x1\",\n \"logsBloom\": \"0x0...\",\n \"effectiveGasPrice\": \"0x77359400\"\n}\n```\n\nQuerying the local `anvil` node confirms that code is deployed:\n\n```bash\n$ cast code 0x5fbdb2315678afecb367f032d93f642f64180aa3\n0x6006600702600055\n```\n\nAnd the initial balance is available:\n\n```bash\n$ cast balance 0x5fbdb2315678afecb367f032d93f642f64180aa3\n5\n```\n\n---\n\nSimulation of contract creation:\n\n![Contract creation](../../images/evm/create-contract.gif)\n\n## Contract code execution\n\nOur simple contract multiplies 6 and 7, then stores the result to storage **slot 0**. Let's execute the contract code with another transaction.\n\nThe transaction payload is similar, except `to` address points to the smart contract, `value` and `data` is empty:\n\n```javascript\n[\n \"0x1\", // nonce (increased by 1)\n \"0x77359400\", // gasPrice (we're paying 2000000000 wei per unit of gas)\n \"0x13880\", // gasLimit (80000 is standard gas for deployment)\n \"0x5fbdb2315678afecb367f032d93f642f64180aa3\", // to address ( address of our smart contract)\n \"0x\", // value (empty; not sending any ether)\n \"0x\", // data (empty)\n];\n```\n\nSign the transaction:\n\n```bash\n\n$ node sign.js '[ \"0x1\", \"0x77359400\", \"0x13880\", \"0x5fbdb2315678afecb367f032d93f642f64180aa3\", \"0x\", \"0x\"]' ac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80\n\nf86401847735940083013880945fbdb2315678afecb367f032d93f642f64180aa380801ba047ae110d52f7879f0ad214784168406f6cbb6e72e0cab59fa4df93da6494b578a02c72fcdea5b7838b520664186707d1465596e4ad4eaf8781a721530f8b8dd5f2\n```\n\nPublish the transaction:\n\n```bash\n$ cast publish f86401847735940083013880945fbdb2315678afecb367f032d93f642f64180aa380801ba047ae110d52f7879f0ad214784168406f6cbb6e72e0cab59fa4df93da6494b578a02c72fcdea5b7838b520664186707d1465596e4ad4eaf8781a721530f8b8dd5f2\n\n{\n \"transactionHash\": \"0xc82a658b947c6083de71a0c587322e8335448e65e7310c04832e477558b2b0ef\",\n \"transactionIndex\": \"0x0\",\n \"blockHash\": \"0x40dc37d9933773598094ec0147bef5dfe72e9654025bfaa80c4cdbf634421384\",\n \"blockNumber\": \"0x2\",\n \"from\": \"0xf39fd6e51aad88f6f4ce6ab8827279cfffb92266\",\n \"to\": \"0x5fbdb2315678afecb367f032d93f642f64180aa3\",\n \"cumulativeGasUsed\": \"0xa86a\",\n \"gasUsed\": \"0xa86a\",\n \"contractAddress\": null,\n \"logs\": [],\n \"status\": \"0x1\",\n \"logsBloom\": \"0x0...\",\n \"effectiveGasPrice\": \"0x77359400\"\n}\n```\n\nRead storage **slot 0** using cast:\n\n```\n$ cast storage 0x5fbdb2315678afecb367f032d93f642f64180aa3 0x\n0x000000000000000000000000000000000000000000000000000000000000002a\n```\n\nSure enough, the result is indeed [42]() (0x2a) 🎉.\n\n---\n\nSimulation of contract execution:\n\n![Contract execution](../../images/evm/contract-execution.gif)\n\n## Receipts\nReceipts are the output artifacts of the EVM state transition function. Each successfully or unsuccessfully executed transaction results in a corresponding receipt as described in the wiki's [data structures](./data-structures.md#receipt-trie) section. Here, we will provide provides additional detail on receipt structure and its evolution.\n\nThe contents of a `receipt` are a tuple of five items:\n- **Transaction Type**: This distinguish between legacy and typed transactions and will be discussed more later.\n- **Status**: The transaction status is either `0` or `1` where `1` indicates a successful transaction and `0` is for a failed transaction.\n- **Gas Used**: Total gas consumed by all previous transactions in the block + the current transaction's gas used.\n- **Logs**: A log entry is a tuple of the logger's address, a possibly empty series of indexed 32-byte log topics, and some number of non-indexed bytes of raw event data.\n- **Logs Bloom**: A 256-byte bloom filter used to quickly search for relevant logs in a block, which allows applications to efficiently check if an address or event signature is included in logs.\n\nSome additional information on how logs bloom is used to allow applications to efficiently check if an address or event signature is included in logs can be found [here](https://medium.com/coinmonks/ethereum-data-transaction-receipt-trie-and-logs-simplified-30e3ae8dc3cf#:~:text=the%20sections%20below.-,Logs%20Bloom,-Assume%20we%20want).\n\nThe `receipt` is committed to the block's **Receipt Trie**.\n\n## Typed Transactions and Receipts\n\nEIP-2718 introduces a unified and extensible format for both transactions and receipts through the concept of *typed envelopes*. This extension simplifies the introduction of new transaction and receipt types, while maintaining full backward compatibility with legacy transactions.\n\nPrior to EIP-2718, adding new transaction types required cumbersome techniques to differentiate them within the constraints of RLP encoding, leading to brittle designs. EIP-2718 solves this by defining a dedicated ***Transaction Type*** prefix.\n\nTransactions after EIP-2718 follow the envelope format: `Typed Transaction = Transaction Type + Transaction Payload`\n\nWhere:\n- ***Transaction Type***: a single-byte identifier specifying the transaction type.\n- ***Transaction Payload***: an opaque byte array defined by the respective transaction type's specification.\n\nNote that legacy transactions are formatted as `RLP([nonce, gasPrice, ..., s])`\n\n### Receipt Encoding\n\nReceipts now adopt the same envelope pattern: `Typed Receipt = Transaction Type + Receipt Payload`\n\nWhere:\n- ***Transaction Type***: a single-byte identifier specifying the transaction type.\n- ***Receipt Payload***: is interpreted based on the associated ***Transaction Type*** definition.\n\nNote that legacy receipts are formatted as `RLP([status, gasUsed, bloom, logs])`\n\nBoth transactions and receipts can be efficiently identified:\n- If the first byte `∈ [0x00, 0x7f]`, it is a **typed** transaction or receipt.\n- If the first byte `≥ 0xc0`, it is a **legacy** transaction or receipt, as dictated by RLP list encoding.\n\n> The first byte of a typed receipt **must** be the same as the `TransactionType` of its associated transaction.\n\nThis rule ensures that clients can deterministically decode receipts without needing additional metadata.\n\nIn summary, EIP-2718 made Ethereum transactions and receipts more extensible while preserving backward compatibility with legacy clients.\n\n## Overview of Transaction Types\n\n### Legacy Transaction (type 0x00)\nLegacy transactions were the only transaction format before [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) introduced the concept of transaction type. Such transactions are still compatible in Ethereum. Even with updates such as [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559), legacy transactions are translated into EIP-1559-compatibility by setting the `max_fee_per_gas` and the `max_priority_fee_per_gas` to the legacy transaction `gas_price`.\n\n### Access List Transaction (type 0x01)\nAccess list transactions are similar to legacy transactions but they also include an optional `access_list` field listing all the addresses and storage slots required to run the transaction.\n\n*Motivation*\n\nIn 2016, attackers targeted the network in an event called the Shanghai DoS attacks by - as the most successful strategy - sending malicious transactions accessing a large amount of addresses and storage slots. The attack forced the clients to search for the information on disk, resulting in IO-heavy transactions that took a long time to process. The attack was low cost for the attacker but high cost for the clients.\n\nAs a result, [EIP-2929](https://eips.ethereum.org/EIPS/eip-2929) was proposed to increase the gas cost of opcodes accessing storage \"cold\" (for the first time, before the data has been copied to RAM). This would have the effect of making further DoS attack economically prohibitive.\n\nEIP-2929 introduced potential contract breakage due to increased gas cost for storage access. Therefore, [EIP-2930](https://eips.ethereum.org/EIPS/eip-2930) introduced an access list (the `access_list` field) specifying all the accounts and storage slots to be accessed in the transaction. As a result, clients could now pre-load the data, resulting in lower gas costs for transactions including an access list.\n\n### Dynamic-Fee Transaction (type 0x02) \nType 2 transactions brought in a new fee market change described in [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) and introduced in the London fork. The network would attempt to maintain a target gas usage per block of 50% of maximum capacity by adjusting the gas base fee. If the current gas usage is higher than the target, gas prices are raised, which lowers demand. If on the other hand, blocks aren't using enough gas, the gas base fee is lowered to compensate, which stimulates demand. The base fee is then burn, reducing the total supply of Eth.\n\nA crucial aspect of this increase or decrease of base fee is that this change can only occur by maximum increments of 1/1024th of the parent's gas limit. This ensures that the gas price can react quickly to changes in demand while also preventing wild fluctuations.\n\nFurthermore, the transaction can include an additional priority fee to incentivize a particular transaction for inclusion in the block over others. This priority fee is not burned but is paid to the validator.\n\n*Motivation*\n\nWhy change the gas fee market in the first place?\nPre-EIP-1559, gas price fluctuated wildly with network demand. A common occurrence was sending a transaction with a particular gas price and having the transaction getting stuck in the mempool due an unexpected spike in gas price. This resulted in a poor user experience, fixed by the newly-added gradual increases of the base fee.\n\nWhy is the base fee burned?\nIn addition to providing an economic benefit to holders of Eth by providing a mechanism for reducing the supply and counterbalancing inflation, the base fee burn mitigates the risks of fee manipulation, preventing validators from flooding the block with \"free\" transactions and keeping gas prices artificially elevated.\n\n### Blob-Carrying Transaction (type 0x03) \n
\n\"blob\"\n\n[EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) introduced short-lived blob data storage which the network keeps available for a temporary period (currently at 4096 epochs, or about 18 days).\n\nThe blobs are not stored on the blockchain, neither on the header or the body. Rather the blob data is sent together with the block - like a sidecar - with the transaction data and made available by the nodes. The header will simply contain a KZG commitment for each blob of data.\n\nSimilarly to EIP-1559 transactions (though the math is different) blob transactions have their own gas price market which adjusts as a function of demand to attain a target usage of 50% of total capacity.\n\n*Motivation*\n\nIn Ethereum, the long term vision for scalability includes both the layer 1 (the execution layer and consensus layer) and layer 2 chains worked together, with the layer 1 providing security guarantees for layer 2. As such, layer 2s are first class citizen in Ethereum. \n\nWe care about blob data availability because maintaining temporarily available data is necessary for servicing layer 2s. For example, optimistic rollups like Optimism optimistically push a commitment of a transaction batch on chain. It's possible that a transaction was maliciously omitted (e.g. Bob has 10 eth, but the committed transactions says he has 0 eth). If that is the case, the user whose funds are compromised can publish a fraud proof to prove bad behavior and correct the situation. Creating this fraud proof requires access to transaction data, hence Ethereum makes this data available for a short period as blobs, giving users a reasonable time to react. Thus, data availability is necessary to ensure compliant state transition of layer 2s. \n\n### Set Code Transaction for EOAs (type 0x04)\nType 4 transactions aims to attach smart contract code to an Externally-Owned Account. Let's recall that EOAs have an empty `code_hash` field, thus they normally have no programs themselves. [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702) changes that by setting the values to the value of `(0xef0100 || delegated_contract_address)` where `||` represents concatenation. Once the code is set, an EOA can delegate its code execution to that of the saved address. It's important to point out that an EOA doesn't hold code itself, but just a pointer towards code. This pointer can be removed or changed with another type 4 transaction. Because we can distinguish between an EOA and a contract, [EIP-3607](https://eips.ethereum.org/EIPS/eip-3607), preventing an attacker from producing an address colliding with an existing contract and stealing funds, can still be respected.\n\nThe value `0xef0100` which precedes the delegated contract address was chosen to provide a unique identifier for which no collision can occur.\nIn effect, `0xef` is a reserved byte according to [EIP-3541](https://eips.ethereum.org/EIPS/eip-3541). The `0100` added afterwards is an identifier to indicate an EIP-7702 delegated address. Thus, it is still possible to distinguish between smart contract and EOAs by looking at the code hash, since EOAs will either have nothing or a value starting with `0xef0100`.\n\n*Motivation*\n\nPure EOA accounts without EIP-7702 suffered from several UX problems. For instance, sending ERC-20 tokens through a smart contract would be done through an `approve/transferFrom` pattern requiring two separate transactions. Account abstraction (smart contract wallets) described in [ERC-4337](https://eips.ethereum.org/EIPS/eip-4337) aimed to fix this issue, in addition to providing additional functionality such as batching of transaction, gas sponsorship, etc...\n\nWith EIP-7702, the Ethereum ecosystem as a whole can now benefit from account abstraction by enabling EOAs to opt-in.\n\n## Appendix A: Transaction signer\n\n`signer.js`: A simple [node.js](https://nodejs.org/) script for signing transactions. See comments for explanation:\n\n```javascript\n/**\n * Utility script to sign a transaction payload array.\n * Usage: node sign.js '[payload]' [private key]\n */\n\nconst { rlp, keccak256, ecsign } = require(\"ethereumjs-util\");\n\n// Parse command-line arguments\nconst payload = JSON.parse(process.argv[2]);\nconst privateKey = Buffer.from(process.argv[3].replace(\"0x\", \"\"), \"hex\");\n\n//validate privatekey length\nif (privateKey.length != 32) {\n console.error(\"Private key must be 64 characters long!\");\n process.exit(1);\n}\n\n// STEP 1: Encode payload to RLP\n// Learn more: https://ethereum.org/en/developers/docs/data-structures-and-encoding/rlp/\nconst unsignedRLP = rlp.encode(payload);\n\n// STEP 2: Hash the RLP encoded payload\n// Learn more: https://ethereum.org/en/glossary/#keccak-256\nconst messageHash = keccak256(unsignedRLP);\n\n// STEP 3: Sign the message\n// Learn more: https://epf.wiki/#/wiki/Cryptography/ecdsa\nconst { v, r, s } = ecsign(messageHash, privateKey);\n\n// STEP 4: Append signature to payload\npayload.push(\n \"0x\".concat(v.toString(16)),\n \"0x\".concat(r.toString(\"hex\")),\n \"0x\".concat(s.toString(\"hex\"))\n);\n\n// STEP 5: Output RLP encoded signed transaction\nconsole.log(rlp.encode(payload).toString(\"hex\"));\n```\n\n## Resources\n- 📝 Gavin Wood, [\"Ethereum Yellow Paper.\"](https://ethereum.github.io/yellowpaper/paper.pdf)\n- 📘 Andreas M. Antonopoulos, Gavin Wood, [\"Mastering Ethereum.\"](https://github.com/ethereumbook/ethereumbook)\n- 📝 Ethereum.org, [\"RLP Encoding.\"](https://ethereum.org/en/developers/docs/data-structures-and-encoding/rlp/)\n- 📝 Ethereum.org, [\"Transactions.\"](https://ethereum.org/en/developers/docs/transactions/)\n- 📝 Random Notes, [\"Signing transactions the hard way.\"](https://lsongnotes.wordpress.com/2018/01/14/signing-an-ethereum-transaction-the-hard-way/) • [archived](https://web.archive.org/web/20240229045603/https://lsongnotes.wordpress.com/2018/01/14/signing-an-ethereum-transaction-the-hard-way/)\n- 🎥 Lefteris Karapetsas, [\"Understanding Transactions in EVM-Compatible Blockchains.\"](https://archive.devcon.org/archive/watch/6/understanding-transactions-in-evm-compatible-blockchains-powered-by-opensource/?tab=YouTube)\n- 🎥 Austin Griffith, [\"Transactions - ETH.BUILD.\"](https://www.youtube.com/watch?v=er-0ihqFQB0)\n- 🧮 Paradigm, [\"Foundry: Ethereum development toolkit.\"](https://github.com/foundry-rs/foundry)\n- [Receipts in Wire Protocol](https://github.com/ethereum/devp2p/blob/master/caps/eth.md) • [archived](https://web.archive.org/web/20250328095848/https://github.com/ethereum/devp2p/blob/master/caps/eth.md)\n- [EiP-2718](https://eips.ethereum.org/EIPS/eip-2718) • [archived](https://web.archive.org/web/20250328095848/https://eips.ethereum.org/EIPS/eip-2718)\n- [Receipt Contents](https://medium.com/coinmonks/ethereum-data-transaction-receipt-trie-and-logs-simplified-30e3ae8dc3cf) • [archived](https://web.archive.org/web/20250000000000/https://medium.com/coinmonks/ethereum-data-transaction-receipt-trie-and-logs-simplified-30e3ae8dc3cf)\n" }, { "path": "docs/wiki/dev/core-development.md", "content": "# Core development \n\n> :warning: This article is a [stub](https://en.wikipedia.org/wiki/Wikipedia:Stub), help the wiki by [contributing](/contributing.md) and expanding it.\n\nThe work on core protocol specification, implementation and testing is commonly referred to as core development. Core devs are contributors the client software, its validation and related tooling for building the protocol, all domains covered in this wiki.\n\nThere are many implementation of both [consensus](/wiki/CL/cl-clients.md) and [execution](/wiki/EL/el-clients.md) layer developed by various independent teams. Together with teams working on research, testing and other infrastructure, core developers are maintaining the base technology used by everyone building on Ethereum.\n\n![Space Core Devs](../../images/space-core-devs.png)\n\n[Hsiao-Wei Wang](https://github.com/hwwhww) shared the graphic above in her presentation _[A Journey of an Ethereum Core Dev/Researcher”](https://www.youtube.com/watch?v=0lBrd2_fPPU)_ she gave at ETHGlobal Tokyo in April 2023. The graphic symbolizes the connection between a space station and the efforts involved from various teams to bring it to life.\n\nTeams working on separate clients are distributed across different organizations, companies or non-profits. They implement the same specification in different languages with various features and performance profiles. The [client diversity](https://ethereum.org/developers/docs/nodes-and-clients/client-diversity) is a fundamental principle embraced by Ethereum. The range of different clients can ensure stability and security of the network while keeping the core development decentralized and open to everyone. \n\nAlthough different teams come from different organization, they all work together and collaborate on improving the whole network. Progress is achieved through discussions in public channels, mainly carried out in weekly meetings. These calls are public and tracked in [project management repo](https://github.com/ethereum/pm), including ACD - Execution and Consensus Layer calls, various \"Breakout Room\" and working group calls. Outside of calls, discussions are held in the Ethereum R&D Discord channel, Eth Magicians forum and EthResearch forum. \n\n# Appendix\n\n[A Day in the Life of a Dev: Ethereum’s Justin Florentine](https://www.coindesk.com/consensus-magazine/2023/02/22/a-day-in-the-life-of-a-dev-ethereums-justin-florentine/)\n\n[Protocol Guild](https://protocol-guild.readthedocs.io/en/latest/)\n\n[Protocol Guild: Funding Core Protocol Stewardship | Cheeky Gorilla - Protocol Guild ETHDenver 2024 Presentation](https://www.youtube.com/watch?v=9Tc2g7pu-gc&ab_channel=ETHDenver)\n\n[Protocol Guild Pledge](https://tim.mirror.xyz/srVdVopOFhD_ZoRDR50x8n5wmW3aRJIrNEAkpyQ4_ng)\n\n[Capital and enclosure in software commons: Linux & Ethereum](https://trent.mirror.xyz/GDDRqetgglGR5IYK1uTXxLalwIH6pBF9nulmY9zarUw)\n" }, { "path": "docs/wiki/dev/cs-resources.md", "content": "# Computer Science Resources\n\n## Introduction / fundamentals\n\n- 🎥 [Map of Computer Science](https://www.youtube.com/watch?v=SzJ46YA_RaA)\n- 🎥 [A Crash Course in Computer Science](https://www.youtube.com/playlist?list=PL8dPuuaLjXtNlUrzyH5r6jN9ulIgZBpdo)\n- 🎥 [Exploring How Computers Work](https://www.youtube.com/playlist?list=PLFt_AvWsXl0dPhqVsKt1Ni_46ARyiCGSq)\n- Building a Modern Computer from First Principles, By Noam Nisan and Shimon Schocken\n - 🎥 [Nand to Tetris Part I](https://www.coursera.org/learn/build-a-computer)\n - 🎥 [Nand to Tetris Part II](https://www.coursera.org/learn/nand2tetris2)\n - 📘 [Book Elements of computing](https://mitpress.mit.edu/9780262640688/the-elements-of-computing-systems/)\n- 📘 [Code: The Hidden Language of Computer Hardware and Software](https://www.amazon.com/Code-Language-Computer-Hardware-Software/dp/0137909101/)\n- 📘 [Computer Science Distilled](https://www.amazon.com/Computer-Science-Distilled-Computational-Problems/dp/0997316020)\n- 🎥 [Information theory | Khan Academy](https://www.khanacademy.org/computing/computer-science/informationtheory)\n\n## Mathematics\n\n- 🎥 [Introduction to Mathematical Thinking | Stanford](https://www.coursera.org/learn/mathematical-thinking)\n- 🎥 [Essence of linear algebra](https://www.youtube.com/playlist?list=PLZHQObOWTQDPD3MizzM2xVFitgF8hE_ab)\n- 📄 [Set Theory](https://www.youtube.com/playlist?list=PL5KkMZvBpo5AH_5GpxMiryJT6Dkj32H6N)\n- 📄 [Basic number theory](https://www.codechef.com/wiki/tutorial-number-theory/)\n- 🎥 [Mathematics for Computer Science | MIT](https://openlearninglibrary.mit.edu/courses/course-v1:OCW+6.042J+2T2019/course/)\n- 📘 [Discrete Mathematics with Applications](https://archive.org/download/schaums-outline-of-basic-mathematics-with-applications-to-science-and-technology-2ed/Discrete%20mathematics%20and%20its%20applications%E2%80%9D%20%288th%20ed%29.pdf)\n\n## Cryptography\n\n- 🎥 [Cryptography I | Stanford](https://www.coursera.org/learn/crypto)\n- 🎥 [Cryptography | Khan Academy](https://www.khanacademy.org/computing/computer-science/cryptography)\n\n## Algorithms\n\n- 🎥 [Computer Science: Algorithms, Theory, and Machines | Princeton University](https://www.coursera.org/learn/cs-algorithms-theory-machines)\n- 📘 [Grokking Algorithms](https://www.amazon.com/Grokking-Algorithms-Second-Aditya-Bhargava/dp/1633438538/)\n- 📘 [Introduction to Algorithms | CLRS](https://www.goodreads.com/book/show/108986.Introduction_to_Algorithms) \n- 🎥 [Introduction to Algorithms | Course with assignments + solutions](https://ocw.mit.edu/courses/6-006-introduction-to-algorithms-spring-2020/)\n- 📘 [Data Structures and Algorithms in C++, 2nd Edition](https://www.amazon.com/Data-Structures-Algorithms-Michael-Goodrich/dp/0470383275)\n\n## Programming\n\n- 🎥 [CS50x: Introduction to Computer Science | Harvard University](https://www.edx.org/learn/computer-science/harvard-university-cs50-s-introduction-to-computer-science)\n- 🎥 [Berkeley CS 61A: Structure and Interpretation of Computer Programs](https://cs61a.org/)\n- 🎥 [Parallel Programming](https://www.coursera.org/learn/scala-parallel-programming)\n- 🎥 [Compilers](https://www.edx.org/course/compilers)\n- [Mastering programming](https://tidyfirst.substack.com/p/mastering-programming)\n- 📄 [Awesome c++ (or C)](https://github.com/fffaraz/awesome-cpp)\n- 📄 [Awesome go](https://github.com/avelino/awesome-go)\n- 📄 [Awesome rust](https://github.com/rust-unofficial/awesome-rust)\n- 📄 [Awesome javascript](https://github.com/sorrycc/awesome-javascript)\n- 📄 [Awesome python](https://github.com/vinta/awesome-python)\n- 🎥 [George Hotz | Programming | rewriting linearizer (tinygrad) | Day In The Life Of A Software Engineer](https://www.youtube.com/watch?v=R-Xr1JRF6bY)\n\n\n## Networking\n\nThis section covers a brief overview of the differences and similarities between the OSI (Open Systems Interconnection) and TCP/IP (Transmission Control Protocol/Internet Protocol) models,\nas well as the protocols involved in the transport layer used in DevP2P: TCP and UDP.\n\nIn terms of networking, both models refer to the same process of communication between layers.\nJust as Kurose and Ross explain (2020), the computer networks are divided into different layers, and each one of them has a specific responsibility. The OSI model has seven layers, while the TCP/IP model has four layers. The OSI model is more theoretical and the TCP/IP model is more practical.\nThe OSI model is a reference model created by the International Organization for Standardization (ISO) to provide a framework for understanding networks. The TCP/IP model was created by the Department of Defense (DoD) to ensure that messages could be transmitted between computers regardless of the types of computers involved.\nThe TCP/IP model is a concise version of the OSI model:\n\n![alt text](../../images/el-architecture/osi-tcpip-models.png)\n\nIn summary, the OSI model layers are:\n1. Physical layer: responsible for the transmission and reception of raw data between devices.\n2. Data link layer: responsible for the node-to-node delivery of the message.\n3. Network layer: responsible for the delivery of packets from the source to the destination.\n4. Transport layer: responsible for the delivery of data between the source and the destination.\n5. Session layer: responsible for the establishment, management, and termination of connections between applications.\n6. Presentation layer: responsible for the translation, compression, and encryption of data.\n7. Application layer: responsible for providing network services directly to the end-user.\n\nAssuming the communication schema proposed by Claude Shannon (1948), every communication implies both a sender and a receiver, a message to be exchanged between them, a transmission medium, and a protocol to be followed.\nThis is important to mention because regardless of the computer architecture, it could be part of a network if it follows the communication and protocol specifications of the models mentioned above.\n\n- 🎥 [Introduction to Computer Networking](https://www.youtube.com/playlist?list=PLEAYkSg4uSQ2dr0XO_Nwa5OcdEcaaELSG)\n- 🎥 [Computers and the Internet | Khan Academy](https://www.khanacademy.org/computing/code-org/computers-and-the-internet)\n- 🎥 [Computer Networking: a Top-Down Approach](https://gaia.cs.umass.edu/kurose_ross/online_lectures.htm)\n- Clause E. Shannon (1948). \"A Mathematical Theory of Communication\". *Bell System Technical Journal*. Vol. 27.\n- Jim Kurose and Keith Ross (2020). *Computer Networking: A Top-Down Approach*. 8th edition. Pearson.\n\n## Distributed systems and blockchain\n\n- 🎥 [Distributed Systems | MIT](https://pdos.csail.mit.edu/6.824/schedule.html)\n- 📄 [Times, Clocks and Ordering of Events in Distributed Systems - Lamport's paper, the Quintessential distributed systems primer](http://research.microsoft.com/en-us/um/people/lamport/pubs/time-clocks.pdf)\n- 📄 [The Byzantine Generals Problem](https://lamport.azurewebsites.net/pubs/byz.pdf)\n- 📄 [Practical Byzantine Fault Tolerance](http://pmg.csail.mit.edu/papers/osdi99.pdf)\n- 📄 [Bitcoin Whitepaper](https://bitcoin.org/bitcoin.pdf)\n- 📄 [Ethereum Whitepaper](https://ethereum.org/en/whitepaper/)\n- 📄 [Mastering Ethereum, by Andreas M. Antonopoulos, Gavin Wood](https://github.com/ethereumbook/ethereumbook)\n- 📄 [Building Blockchain in Go](https://github.com/Jeiwan/blockchain_go)\n\n## Security\n\n- 🎥 [Security Engineering](https://www.cl.cam.ac.uk/~rja14/book.html)\n- 🎥 [Computer Systems Security](https://ocw.mit.edu/courses/6-858-computer-systems-security-fall-2014/)\n- 🎥 [CS 161: Computer Security](https://sp21.cs161.org/)\n- 🎥 [Secure Software Development: Requirements, Design, and Reuse](https://www.edx.org/course/secure-software-development-requirements-design-and-reuse)\n- 🎥 [Secure Software Development: Implementation](https://www.edx.org/course/secure-software-development-implementation)\n\n## Terminals, shell scripting, and version control\n\n- 🎥 [The Missing Semester of Your CS Education | MIT](https://missing.csail.mit.edu/)\n- 🎥 [The Unix Workbench | Johns Hopkins](https://www.coursera.org/learn/unix)\n- 📄 [Git tips and tricks](https://blog.gitbutler.com/git-tips-and-tricks/)\n- 📄 [Popular Git config options](https://jvns.ca/blog/2024/02/16/popular-git-config-options/)\n\n## Misc\n\n- 📄 [Things Every Programmer Should Know](https://github.com/mtdvio/every-programmer-should-know)\n- 📄 [What Every Programmer Should Know About Memory](https://akkadia.org/drepper/cpumemory.pdf)\n- 📄 [What Every Computer Scientist Should Know About Floating-Point Arithmetic](https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html)\n- 🗣️ [Big and Little Endian inside / out](https://www.youtube.com/watch?v=oBSuXP-1Tc0)\n- 🎥 [The Perfect Dependency - SQLite Case Study](https://www.youtube.com/watch?v=ZP7ef4eVnac)\n\n## Resources\n\n- [\"Teach Yourself Computer Science\"](https://teachyourselfcs.com/)\n- [\"Open Source Society University\"](https://github.com/ossu/computer-science)\n- [\"Coding Interview University\"](https://github.com/jwasham/coding-interview-university)\n- [\"The Open Source Computer Science Degree\"](https://github.com/ForrestKnight/open-source-cs)\n" }, { "path": "docs/wiki/dev/pm.md", "content": "# Core development coordination \n\n> :warning: This article is a [stub](https://en.wikipedia.org/wiki/Wikipedia:Stub), help the wiki by [contributing](/contributing.md) and expanding it.\n\nBecause of the approach of client diversity and decentralization, Ethereum core development is spread across many teams from various organizations. Roughly estimated, there is around 200+ client developers, researchers, testers and other contributors split across ~20 teams. \n\nTo effectively maintain and implement various initiatives affecting the Ethereum protocol, all of these people need be able to reach consensus and collaborate in a productive manner. Generally, this is possible thanks to free and open source nature of Ethereum and it's design and development based unix philosophy but still requires lot of coordination work. \n\n## Ethereum PM repository\n\nThe [ethereum/pm](https://github.com/ethereum/pm) repository is used for Ethereum project management purposes. It serves as a coordination for planning developer calls and archiving their recordings. \n\n*main use:*\n - Execution and Consensus Layer AllCoreDevs meetings\n\n*secondary uses:*\n - Breakout Rooms on various protocol-related topics (e.g. EOF, account abstraction, etc)\n - There's a Google Calendar tracking upcoming protocol meetings.\n\n### Resources\n\n- [Ethereum Governance by Tim Beiko](https://hackmd.io/@timbeiko/eth-governance)\n" }, { "path": "docs/wiki/epf.md", "content": "# Ethereum Protocol Fellowship Cohort 7 \n\nEPF opens its doors once again with new cohort 7 in 2026! Learn more about the program and find the application below.\n\n### Town Hall\n\nAn introductory town hall will be held on May 6 at 15:00 UTC. [Add it to your calendar](https://calendar.google.com/calendar/event?action=TEMPLATE&tmeid=MG8wdDEzMGtqYXNxZTFqdWw3NWVsNWphbWggY18xY2RhMjMxNzc5NmI4NDgzZTliMjBhMGVjZTFkMDFhZWFkN2U1ZTY3N2IxNjVhOGUzZTJlMjQ3ZTQ0M2UwODhkQGc&tmsrc=c_1cda2317796b8483e9b20a0ece1d01aead7e5e677b165a8e3e2e247e443e088d%40group.calendar.google.com) and join us to ask any questions about the upcoming cohort at meet.ethereum.org/epf-town-hall \n \n### Application \n\n**Fill the application before May 13 deadline**\n\n\n\nother resources:\n\n- [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702)\n- [EIP-7702 Discussion](https://ethereum-magicians.org/t/eip-7702-account-abstraction/)\n- [Decoding 7702](https://medium.com/inception-capital/decoding-vitaliks-eip-7702-507c56f9f70c)\n" }, { "path": "docs/wiki/research/cl-upgrades.md", "content": "# Beacon Chain upgrades\n\n### Inclusion Lists\n### Preconfirmations\n### Raise MAX_EFFECTIVE_BALANCE\n### Staking pools solutions\n\n* [Minimal viable enshrinement of liquid staking](#resources)\n\n### RESOURCES\n[Wiki Roadmap](https://github.com/eth-protocol-fellows/protocol-studies/pull/78)\n\n[ethereum/EIPs github repository](https://github.com/ethereum/EIPs/tree/master#ethereum-improvement-proposals-eips)\n\n[notes on Minimal viable enshrinement of liquid staking](https://gist.github.com/gorondan/671062f279542bcaca80f0faec53c0a4)\n\n[Ethresearch](https://ethresear.ch/)\n" }, { "path": "docs/wiki/research/eODS.md", "content": "# Enshrined Operator-delegator separation (eODS)\n\n> [!WARNING]\n> This document covers an active area of research, may be outdated at time of reading and subject to future updates, as the design space around Validator roles unbundling evolves.\n\n## Roadmap tracker\n\n| Upgrade | URGE | Track | Item | Cross-references |\n|:-------:|:-----------:|:-----------------:|:-------------------------------------------------------:|:-----------------------------------------------------------------------------------------------------------------------------------------------:|\n| eODS | the Scourge | Staking economics | Censorship resistances, liquid staking decentralization | [SSF](/docs/wiki/research/SSF.md), [IL](/docs/wiki/research/cl-upgrades.md), [ePBS](/wiki/research/PBS/ePBS.md), [ET](/wiki/research/PBS/ET.md) |\n\n## Relevant context \n\nPrincipal–Agent problem of liquid staking, in which the interests of the Agent are not aligned with the interests of the Principal, is part of any capital delegation, and even more so present in today's staking ecosystem[^1].\n\nSince the early days of Beacon Chain, market structures enabling to provide liquidity for staking pools without running an actual validator software have emerged in Ethereum.\nThus, staking has split naturally in two classes of participants, outside protocol level[^2]:\n\n| Tier | Current natural separation | Slashing risk |\n|:----------:|:----------------------------------------------------------------------------------------------------------------------------------------:|:-------------:|\n| Delegators | ETH stakers with no minimum commitment and no strict requirement to participate in any other way beyond bringing in their principal | Slashable |\n| Operators | Node operators, home staking or providing validator services, with their reputation or some fixed amount of capital of their own at risk | Slashable |\n\nThe two tiers are closely interlinked, as liquid staking protocols are not credible if their liquid staking token (LST) holders do not believe that the operators holding their principal are *good agents*. \n\nThe risk of slashing, coupled with the high amount of revenue paid out in aggregate to Gasper service providers via issuance, results in intermediate chains of **principal-agent relationships**[^3]. Delegators provide capital (Principal) to operators who participate in Gasper on their behalf, in order to earn staking rewards for the Principal and themselves. \nHowever, if the validator misbehaves, the funds of the delegator are also slashed, as the actions of the validator (the Agent) affect the capital of the delegator (the Principal).\n\nIn order to be considered good agents, honest operators must commit to the Principal's interests:\n- perform validation duties properly (i.e. run and maintain good staking infrastructure, be diligent so that its online reputation is upheld by showing high participation rate, and running the prescribed protocol, hence never equivocate by signing conflicting blocks) \n- agents must not be adversarial (malicious), deviating from the protocol arbitrarily, e.g. equivocating and getting slashed in the attempt to obtain under-evaluated stake for the purpose of attacking the network.\n\n## What is eODS?\n\neODS is an actively discussed design space[^4] within Ethereum, proposing an even further separation of the role of **Validator** (unbundling), to be implemented at protocol level, closing the loop in the Staking economics track of the Scourge, between ePBS and Execution tickets.\n\n### Unbundling the Validator role\n\n| Upgrade | Separation type |\n| ------- | ------------------ |\n| ePBS | proposer-builder |\n| ET | validator-proposer |\n| eODS | operator-delegator |\n\nThis separation addresses various inefficiencies associated with the limits of what the protocol sees[^5], and its capacity to react with automated defense systems, in the context of ETH staking.\n\n## The two-tier staking approach to SSF\n\nIn the [SSF](/docs/wiki/research/SSF.md) research discourse, technical limitations associated with per slot BLS signatures aggregation generates the following paradigm:\n> We need to move away from the concept that every participant signs in every slot - Vitalik Buterin\n\nIn the above context, there's value in the proposal to **split staking** in two tiers of participants:[^23]\n * **A high-complexity tier** called in to act every slot but has only ~ 10,000 participants, providing **Heavy node services**, and\n * **A lower-complexity tier** only called up to participate occasionally, providing **Small(light) node services** with low computational overhead, hardware or technical know-how requirements.\n\nThe providers of heavy node services would be subject to slashing, but also highly rewarded for participating in the protocol's Finality gadget, while the providers of small node services would be entitled to lower rewards, but could be entirely exempt from slashing (do not actively participate in each slot), or could opt in to temporarily (i.e. for a few slots) become subject to slashing.\n\n## The role of Delegators\n\nIn his October 2023 paper, called \"Protocol and staking pool changes that could improve decentralization and reduce consensus overhead\", Vitalik poses a key question: **from the protocol’s perspective, what is the point of having delegators at all?**[^6]\n\nVitalik takes a thought experiment, hypothesizing a world where bounding the maximum slashing penalty to 2 ETH is a reality.[^7].\n\nTwo scenarios are run and compared under the above premises:\n1. because the slashing and leaking penalties are capped, Rocket Pool reduces operator bond accordingly, to 2 ETH, all ETH is staked and Rocket Pool as a LSP (liquid staking protocol) absorbs 100% of the market share (not just among stakers, but also among ETH holders. As rETH becomes risk-free, almost all ETH holders become rETH holders or node operators).\n2. in the second scenario, Rocket Pool does not exist as an LSP. Minimum deposit amount is reduced to 2 ETH, and total staked ETH is capped at 6.25M. Also, the node operator’s return is decreased to 1%.\n\nThe two scenarios were run from both a staking economics perspective, and a cost-of-attack perspective.\nAfter performing the calculations, the final outcome in both cases was exactly the same, so, theoretically, the protocol would be better off cutting out the middleman, and drastically reduce staking rewards and cap total ETH staked to 6.25M.\n\nThe scope of the argument above was not to advocate for reducing staking rewards, nor for capping total staked ETH, but to point out a key property that a well-functioning staking system should have: \n \n>**Delegators should be doing something that actually matters** - *Vitalik Buterin*\n\n### Delegators role under eODS\n\nIf Delegators were to have a **meaningful role**, what would that be, and how can the protocol **incentivize** that role selection?\n\nTwo possible solutions[^8] arise, under Operator-Delegator separation:\n1. **The curation of operator set**: Opinionated delegators may decide to choose between different operators based on e.g., fees or reliability.\n2. **The provision of light services**: The delegators may be called upon to provide non-slashable, yet critical services, like:\n - input their view into censorship-resistance gadgets such as inclusion lists or multiplicity gadgets.\n - sign off on their view of the current head of the chain, as alternative signal to that of the bonded Gasper operators. \n\n**Incentivizing the Delegator role**: \n\nDelegators under this model do not contribute to the economic security of FFG, i.e. Delegators do not partake in Finality (non-slashable stake), but they are able to surface discrepancies in the gadget’s functioning. Their services can be compensated by re-allocated aggregated issuance.\n\n## The layers of Operator-Delegator Separation\neODS taken in isolation, enshrines the separation, but brings no improvement to the existing market structure:\n| 1D-eODS | |\n| --------- | --------- |\n| OPERATOR | DELEGATOR |\n| slashable | slashable |\n\nIn order for eODS to be relevant, it must be considered holistically, together with other relevant, proposed, protocol changes:\n\n* Capping penalties:\n | 1D-eODS + capping penalties | |\n | --------------------------- | ------------- |\n | OPERATOR | DELEGATOR |\n | slashable | non-slashable |\n\n In this model, by capping the slashing and leaking penalties to only the operator’s stake, assets of delegators are no longer at risk. However, Barnabé argues[^4] that the role of Delegator is not very clear under 1D-eODS, because of the following reasons:\n * Delegators in the two-tiered staking model are unlike delegators of current LSPs, who bear the slashing risk.\n * Some agents would wish to delegate their assets to “two-tier operators” and subject themselves to the slashing conditions, in search for yield.\n * Some agents would wish to not operate small node services themselves, yet participate in their provision by delegating operations instead.\n\n More, in the context of MVI, implementing penalties slashing in the way presented above, would be economically equivalent to reducing staking yield to 1% and just making staking an explicitly altruistic activity.[^9]\n\n* The above issues can be resolved by the **Introduction of two distinct types of protocol services**, based on the [Two-tier staking approach](#the-two-tier-staking-approach-to-ssf):\n * ***Heavy Services***\n * ***Light Services***\n \n This *design philosophy* produces a separation of the role of Validator in 2 dimensions (2D Operator-Delegator Separation), each dimension inducing within itself a market structure of delegators and operators:\n\n | 2D-eODS (rainbow staking) | | |\n | ------------------------- | --------------- | ------------- |\n | Light OPERATOR | Light DELEGATOR | non-slashable |\n | Heavy OPERATOR | Heavy DELEGATOR | slashable |\n\n ### Economics of light services \n Light services use stake as *sybil-control* mechanism and as *weight functions*.[^10]\n\n The protocol will offer an ecosystem of light services such as censorship resistance gadgets, which are provided using weak hardware and economic requirements. \n Censorship-resistant, in protocol gadgets reward participants that help the protocol \"see\" censored inputs via some mechanism like inclusion lists. \n \n These light services are compensated by re-allocating aggregate issuance towards their provision, a pattern already in use today for sync committees.[^11]\n\n Light holders (Delegators) can delegate their assets to light service operators, performing the service on behalf of the delegator for a fee, which aligns the incentives of the operator to maximize the reward for the delegator. In a competitive marketplace of light operators, along with re-delegation allowing for instant withdrawal from a badly performing operator, light operators would be expected to provide the service for marginal profitability and with cost efficiency.\n \n **Partially slashable light services**\n\n Some light services may require slashable stake. A variant of the penalties capping approach could be enforced, with only the operator stake is slashable. \n\n | 2D-eODS (rainbow staking) | + penalties capping |\n | ------------------------- | ----------------------------- |\n | Light OPERATOR slashable | Light DELEGATOR non-slashable | |\n | Heavy OPERATOR slashable | Heavy DELEGATOR slashable |\n\n ### Economics of heavy services\n Heavy services use stake as *economic security*[^12]\n \n Should their stake participate in an FFG safety fault (conflicting finalized checkpoints), all of their stake will be lost.\n\n The requirements of heavy services such as FFG, Ethereum’s Finality gadget, will be strengthened to achieve Single-Slot Finality (SSF). \n \n Possible enshrined protocol gadgets that will help foster a safe staking environment:\n * liquid staking module (LSM)-style primitives to build liquid staking protocols on top of\n * enshrined partial pools or DVT networks\n \n All allowing for fast re-delegation among other features.\n\n ### Mechanism design (Heavy vs. Light)\n | | Heavy services | Light services |\n | ----------------------------- | ---------------------------------------------------------------------------- | -------------------------------------------------------------------------- |\n | Service archetype | Gasper | Censorship-resistance gadgets |\n | Reward dynamics | Correlation yields rewards usually, anti-correlation is good during faults | Anti-correlation yields rewards (surface different signals) |\n | Slashing risk | Operators and delegators | None or operators only |\n | Role of operators | Run full node to provide Gasper validation services | Run small node to provide light services |\n | Role of delegates | Contribute economic security to Gasper | Lend weight to light operators with good service quality |\n | Operator capital requirements | High capital efficiency (high stake-per-operator) + high capital investments | Not really a constraint (operators receive weight) + small node fixed cost |\n | Solo staker access | Primarily as part of LSPs (e.g., as DVT nodes) | High access for all light services |\n\n## Unlocking re-staking? \n\neODS (the 2D model) can be considered a partial enshrinement of re-staking, thanks to re-stakers being able to commit to this new class of protocol AVS (actively validated service)[^13] for which rewards are issued from the creation of newly-minted ETH(i.e. Gasper is an protocol AVS with a well known issuance schedule)[^14]. \n \nETH holders are then allowed to enter into the provision of these AVS, either directly as operators, or indirectly as delegators.\n\n## Where do Solo Stakers fit in this new world?\nGasper (and a variant of it in SSF scenario) is the heaviest AVS of the Ethereum protocol. It receives the highest share of aggregate issuance, so there are many parties interested in providing the required stake, in an delegated staking scheme[^3], with Delegators providing stake to Operators who participate in Gasper on their behalf.\n\nGiven the induced intermediation of stake, it is necessary to prevent the emergence of a single dominant liquid staking provider collateralized by the majority of the ETH supply. Minimum Viable Issuance (MVI)[^15] measures are critical in order to target sufficient security for the protocol, by creating sufficient pressure to keep the economic weight of Gasper in the right proportion. \n\nDue to the fact that solo stakers are unable to issue credible liquid staking tokens from their collateral and have thus low capital efficiency, MVI-imposed competitive pressures is not well-suited for them. In the context of eODS, this disadvantage can be greatly improved.\n\n### The role of solo stakers, under eODS\nIn his \"Unbundling staking: Towards rainbow staking\" research post[^16], Barnabé offers two core value propositions which solo stakers embody ideally:\n\n* **Bolster network resilience**: Solo stakers bolster the resilience of the network to failures of larger operators, e.g. by progressing the (dynamically available) chain while large operators go offline. It would not be their main line of operators due to capital and cost-efficiency limitations, but it could be a strong fallback in the worst case scenario.\n \n* **Generators of preference entropy**: Solo stakers may contribute as censorship-resistance agents, allowing the protocol to see more and serve a wider spectrum of users. Performing such a light service is at hand for a wide class of low-powered participants. Multiplicity gadgets could reward the contributions of operators who increase preference entropy[^16]. \n\nPreference entropy denotes information surfaced by protocol agents to the protocol.Agents who censor have lower preference entropy, as they decide to restrict the expression of certain preferences, such as activities which may contravene their own jurisdictional preferences. \nThe set of solo stakers who operate nodes to provide services is highly decentralized, and is thus able to express high preference entropy. This economic value translates into revenue for members of the set.\n\n## Why separate?\n\n### Social layer leverage\nThere are risks in relying too much on the social layer and morality to protect the protocol against centralization in the staking scene and countering the emergence of a dominant LST with its associated perils\n\n### Already an established model\neODS would mean enshrining a variant of the already established staking model with two classes of participants: delegators (stakers) and node operators\n\n### Enabling stronger forms of consensus participation for Delegators.\nIn order to improve delegate selection powers[^17], we can:\n\n* improve voting tools within pools\n \n Under the current paradigm, voting within staking pools is limited to governance token-holders (not ETH holders). There are attempts of Optimistic governance, where ETH holders can veto LSP governance votes, but (paraphrasing Vitalik) token voting is not strong enough, and ultimately any form of unincentivized delegate selection is just a type of token voting.\n\n* improve competition between pools\n \n The challenges of smaller liquid staking protocols that have small market capitalization are that they are less liquid, harder to trust, and less supported by applications. Capping penalties and 1D-eODS could theoretically help with these challenges, but the actual implementation of the bounding of penalties is not feasible, for the [reasons expressed above](#the-layers-of-operator-delegator-separation).\n\n* enshrine delegation\n \n eODS offers stronger forms of consensus participation for Delegators, either \n - as capital providers to Operators who participate in chain Finality on their behalf (heavy services, slashable), or\n - as participants in censorship resistance gadgets like Inclusion lists or Multiplicity gadgets (light services, not slashable), or\n - sign off as alternative signal to Finality participants (light services, not slashable).\n \n### Reduce the number of BLS signatures (SSF scenario)\nEthereum is constantly improving and growing on its way to becoming the envisioned global-scale network.\n\nIn this scenario, single-slot finality is not only desirable but most likely mandatory, and good trade-offs are needed on the path towards SSF.\n\nIn the above context, we can assume a limit between $100k - 1.8 million$ BLS signatures that could be processed every slot. \neODS proposes a smaller number of Validators, as heavy services providers ($<10,000$), reducing the number of BLS signatures that need to be processed every slot, even assuming single slot finality. \n\n### Synergies with active R&D space\n\n**Execution tickets**\n\neODS fits well in a world where the role of the Validator [is disambiguated](#unbundling-the-validator-role). The essence of Execution Tickets[^18] is to separate execution from consensus, and that helps achieving MVI[^15] for Heavy Operators. If execution services are separated from consensus services under ET (or a similar attester-proposer separation), heavy operators would be less concerned with reward variability and playing Timing games[^19] when finalizing the output of the execution service (the payload)\n\n**Inclusion lists & Multiplicity gadgets**\n\nLight services act as a constraint to payload services, by including them in censorship-resistant gadgets such as IL or MG.\n\nInclusion lists[^20] prepared by honest validators function as censorship signals and defense against systematic censorship from identifiable validators. Attesters uphold the validity and the satisfaction of an inclusion list, via the fork choice.\n\nMultiplicity gadgets[^21] are related to IL, but propose a mechanism of assigning the responsibility of constructing an inclusion set to a committee instead of a single leader (like IL), thus avoiding the reliance on the honesty or rationality of a single party. Obtaining consensus over the set of items to include could also increase accountability and allow for incentive schemes.\n\nWhile the exact constraining mechanism of Light services (e,g, IL) over execution payload producers needs to be further researched and developed, separating *producers* from *enforcers* under eODS would bring an improvement to today's IL design, where Validators act as both producers and enforcers.\n\nSeparating services, the Light operators become producers of the list, but the validity of the execution payload with respect to Gasper is enforced by Heavy operators, who attest and finalize the valid history of the chain, ignoring invalid payloads. \n\n**MAX_EFFECTIVE_BALANCE**\n\nEIP-7251[^22] will allow a single message to carry more stake. Enshrining the operator delegator separation would provide a way for the protocol to functionally distinguish “operator stake” from “delegator stake” on such a message, further separation of each tier in heavy services providers and light services providers.\n\n### Future protocol services\neODS provides an interface to integrate further “protocol services” in a plug-and-play manner.\n\n## The road ahead\nFrom a high level view, the two dimensions of eODS could be implemented as follows:\n- the Vertical dimension of the separation, being the Light - Heavy services separation can be done in practice, by increasing MAX_EFFECTIVE_BALANCE[^22] and later implementing a balance threshold of e.g. 2048 ETH to determine which validators enter which complexity tier.\n- the Horizontal dimension of the separation, being the Operator-Delegator separation can be done by the means presented in [this section](#the-layers-of-operator-delegator-separation).\n\nFurther R&D is required on the exact MVI to be targeted for each (heavy & light) type of protocol services, and the practical applications and implementation of eODS. \n\nRegarding the enshrinement of liquid staking, Vitalik states:\n> It may still be better to enshrine some things outright, but it's valuable to note that this \"enshrine some things, leave other things to users\" design space exists.[^7]\n\n## [References]\n\n[^1]: https://eprint.iacr.org/2023/605\n\n[^2]: https://notes.ethereum.org/@vbuterin/staking_2023_10#Protocol-and-staking-pool-changes-that-could-improve-decentralization-and-reduce-consensus-overhead\n\n[^3]: https://mirror.xyz/barnabe.eth/v7W2CsSVYW6I_9bbHFDqvqShQ6gTX3weAtwkaVAzAL4\n\n[^4]: https://ethresear.ch/t/unbundling-staking-towards-rainbow-staking/18683#operatordelegator-separation-2\n\n[^5]: https://barnabe.substack.com/i/95811604/case-studies-in-upgrading-the-fence\n\n[^6]: https://notes.ethereum.org/@vbuterin/staking_2023_10#The-role-of-delegators\n\n[^7]: https://vitalik.eth.limo/general/2023/09/30/enshrinement.html#enshrining-liquid-staking\n\n[^8]: https://notes.ethereum.org/@vbuterin/staking_2023_10#If-delegators-can-have-a-meaningful-role-what-might-that-role-be\n\n[^9]: https://youtu.be/ZBvV88jEkiA?t=2561\n\n[^10]: https://ethresear.ch/t/unbundling-staking-towards-rainbow-staking/18683#economics-of-light-services-5\n\n[^11]: https://eth2book.info/capella/part2/incentives/rewards/#proposer-rewards-for-sync-committees\n\n[^12]: https://ethresear.ch/t/unbundling-staking-towards-rainbow-staking/18683#economics-of-heavy-services-4\n\n[^13]: https://docs.eigenlayer.xyz/eigenlayer/avs-guides/avs-developer-guide#what-is-an-avs\n\n[^14]: https://eth2book.info/capella/part2/incentives/issuance/\n\n[^15]: https://notes.ethereum.org/@anderselowsson/MinimumViableIssuance\n\n[^16]: https://ethresear.ch/t/unbundling-staking-towards-rainbow-staking/18683#staking-economics-in-the-rainbow-world-6\n\n[^17]: https://notes.ethereum.org/@vbuterin/staking_2023_10#Expanding-delegate-selection-powers\n\n[^18]: https://ethresear.ch/t/execution-tickets/17944\n\n[^19]: https://ethresear.ch/t/timing-games-implications-and-possible-mitigations/17612\n\n[^20]: https://eips.ethereum.org/EIPS/eip-7547\n\n[^21]: https://efdn.notion.site/ROP-9-Multiplicity-gadgets-for-censorship-resistance-7def9d354f8a4ed5a0722f4eb04ca73b\n\n[^22]: https://eips.ethereum.org/EIPS/eip-7251\n\n[^23]: https://ethresear.ch/t/sticking-to-8192-signatures-per-slot-post-ssf-how-and-why/17989#approach-2-two-tiered-staking-4\n" }, { "path": "docs/wiki/research/history-expiry/history-expiry.md", "content": "# History Expiry In Ethereum\n\n> **Recommended pre-reading**\n> - [Ethereum Node Architecture](/wiki/EL/el-specs.md)\n> - [Execution Layer Specification](/wiki/EL/el-specs.md)\n> - [DevP2P protocol](/wiki/EL/devp2p.md)\n> - [Data structures and encoding](/wiki/EL/data-structures.md)\n> - [EIP-4444: Bound Historical Data in Execution Clients](https://eips.ethereum.org/EIPS/eip-4444)\n> - [EIP-7643: History Accumulator for Pre-PoS Data](https://eips.ethereum.org/EIPS/eip-7643)\n\nHistory expiry is the idea that nodes should not be required to store historical data forever. Every Ethereum full node stores two categories of data. State is the current account, contract storage, and code. History is past block headers, bodies, and receipts.\n\nUp until recently, full nodes were expected to store and serve all historical data, over the peer-to-peer network, even if the data is not needed to validate a block. That data has grown with every block since genesis. Today, running a full node takes well over a terabyte of disk space, and both client load and sync times keep increasing even as the chain's capacity remains the same. Removing this data might sound risky, but Ethereum's default sync strategy already does not validate every block from genesis. [Snap sync](https://ethereum.org/en/developers/docs/nodes-and-clients/#snap-sync) starts from a recent state snapshot and [weak subjectivity checkpoints](https://epf.wiki/#/wiki/CL/syncing) anchor the chain to a trusted finalized point. Although historical validation is still possible, it is not compulsory.\n\nTo solve this, [EIP-4444](https://eips.ethereum.org/EIPS/eip-4444) proposes that nodes may prune historical data and receipts older than a set threshold and stop serving them over the peer-to-peer network. Once a client has synced to the tip of the chain, historical data is only retrieved when requested explicitly over the JSON-RPC or when a peer attempts to sync. For this to work, the peer-to-peer protocol itself needed to change.\n\n## DevP2P Changes\n\nUnder `eth/68` and older `eth` protocols, nodes assumed every peer stored the full chain from genesis. A node pruning old history while still advertising itself on `eth/68` would break that assumption and disrupt sync for peers requesting old blocks. [EIP-7642](https://eips.ethereum.org/EIPS/eip-7642) introduces `eth/69`, which removes this assumption. Prior to `eth/69`, when two nodes connect, they exchange a Status message containing the network ID, genesis hash, fork ID, and the hash of the node's latest block, but now the status handshake includes two new fields, `earliestBlock` and `latestBlock` that store the block range.\n\n```python\n # Old eth/68 Status\n # [version, networkid, td, blockhash, genesis, forkid]\n\n # New eth/69 Status\n # Now includes earliestBlock and latestBlockHash.\n # td (totalDifficulty) is removed as it is useless since the merge.\n # [version, networkid, genesis, forkid, earliestBlock, latestBlock, latestBlockHash]\n\n # BlockRangeUpdate message, sent when a node's range changes.\n # Sent at most once per epoch (32 blocks).\n # [earliestBlock, latestBlock, latestBlockHash]\n```\n\n`eth/69` also adds a new message, BlockRangeUpdate. As a node prunes more data or downloads more history, it sends this message to its connected peers so they can update their view of what blocks that node can serve. This only needs to be sent once per epoch.\n\n`eth/69`'s linear range works for Phase 1 where nodes either hold pre-Merge (old PoW chain) data or they don't. For Phase 2, where nodes may hold non-contiguous slices of history, proposals like [EIP-7801](https://eips.ethereum.org/EIPS/eip-7801), introduce a bitmask-based subprotocol called `etha` that lets nodes advertise exactly which segments of the chain they store. While the eth protocol continues to handle live chain operations like block propagation, transaction gossip, and syncing to the tip, the `etha` subprotocol is dedicated entirely to serving historical data. This means historical block requests will no longer travel over the same channel as live chain, so a node that is looking for old blocks queries peers over etha, and nodes that do not support history sharding are never bothered with those requests again.\n\nThe core idea of `etha` is that the chain history will be divided into repeating windows of 1,064,960 blocks. Each window is split into 10 equal spans of 106,496 blocks. Each bit in the bitmask represents one of those spans. If a node sets bit 3, that node is committing to hold every third span out of ten not just in the segment alone, but the entire chain from blocks 0 through 1,064,960, and from blocks 1,064,960 through 2,129,920, and so on all the way to the chain head. As new blocks are produced and new spans are created, the node must continue storing the spans that correspond to its committed bit.\n\n**Window: Blocks 0 — 1,064,960**\n\n| | Span 0 | Span 1 | Span 2 | Span 3 | Span 4 | Span 5 | Span 6 | Span 7 | Span 8 | Span 9 |\n|--------------|--------|--------|--------|--------|--------|--------|--------|--------|--------|--------|\n| Node A | X | | | | | | | | | |\n| Node B | | | | X | | | | | | |\n| Node C | | | | | | | | X | | |\n| Node D | | X | | | | | | | | |\n| Node E | | | | | | X | | | | |\n| Node F | | | | | | | | | | X |\n\nThe span sizes of 106,496 are not arbitrary. Each span is a multiple of 8,192 blocks, which is the maximum block range of an ERA1 file. This makes a node's storage and retrieval align directly with how data is packaged for distribution, and backfilling a shard straightforward. The minimum requirement is that each participating node retains at least one bit, which translates to roughly 10% of total chain history giving a 90% storage reduction compared to holding everything. A syncing node finding a particular shard depends on how many of its peers hold it. The probability that none of a node's peers hold a given shard is modeled as $(0.9)^n$, where $n$ is the number of connected peers. With 25 peers, there is roughly a 7% chance a shard is missing and with 32 peers that drops to about 3.4%.\n\n| Number of Connected Peers ($n$) | Probability No Peer Holds a Given Shard $P = (0.9)^n$ | Probability At Least One Peer Holds It $1 - (0.9)^n$ |\n|---------------------------------|-------------------------------------------------------|-------------------------------------------------------|\n| 10 | 34.9% | 65.1% |\n| 15 | 20.6% | 79.4% |\n| 20 | 12.2% | 87.8% |\n| 25 | 7.2% | 92.8% |\n| 32 | 3.4% | 96.6% |\n| 50 | 0.5% | 99.5% |\n\nWhen two nodes connect over etha, they exchange a handshake containing the same fields as eth/69 plus the `blockBitmask`. From that point, the node can serve historical data using four messages reused directly from eth/69 with identical encoding such as `GetBlockBodies`, `BlockBodies`, `GetReceipts`, and `Receipts`. This makes the data retrieval process work the same way, and no new message types are needed.\n\n```python\n # eth/69 Status Handshake\n # [version, networkid, genesis, forkid, earliestBlock, latestBlock, latestBlockHash]\n\n # etha Handshake (EIP-7801)\n # Same fields as eth/69, plus a 10-bit blockBitmask\n # [version, networkid, genesis, forkid, blockhash, blockBitmask]\n\n # etha reuses these four messages from eth/69 with identical encoding\n # GetBlockBodies (0x05)\n # BlockBodies (0x06)\n # GetReceipts (0x0f)\n # Receipts (0x10)\n```\n\n## Deposit Log Dependency\n\nHistory expiry does not only affect the execution layer but it poses a direct problem for the consensus layer. Before the [Pectra hardfork](https://eips.ethereum.org/EIPS/eip-7600), when someone deposits 32 ETH to become a validator, that transaction goes to the deposit contract on the execution layer, and then emits a `DepositEvent` log that contains the validator's public key, withdrawal credentials, deposit amount, signature, and index. The consensus layer needs this information to onboard the validator.\n\n```python\n # From github.com/ethereum/consensus-specs\n # event DepositEvent(\n # bytes pubkey, # The validator's public key\n # bytes withdrawal_credentials, # Address to receive the validator's balance when it exits\n # bytes amount, # How much ETH was deposited\n # bytes signature, # Validator's signature\n # bytes index # Index tracks the number of deposits\n # )\n```\n\nConsensus layer clients got this data through a mechanism called the Eth1Data poll. Every beacon block included an `eth1_data` field where the block proposer voted on a recent state of the deposit contract. To be able to vote, the consensus client of the proposer would query the execution client over JSON-RPC, asking it to read the deposit contract's logs from historical execution layer blocks. The execution client would scan back through old blocks to find the relevant deposit events, and that is exactly where history expiry breaks things.\n\n```mermaid\ngraph TD\n A[User deposits 32 ETH] --> B[Deposit Contract]\n\n subgraph After EIP-6110\n A1[EL extracts deposit] --> A2[In execution payload] --> A3[CL reads payload] --> A4[CL onboards]\n end\n\n subgraph Before EIP-6110\n B1[Log in receipt] --> B2[CL polls EL] --> B3[EL scans history] --> B4[CL onboards]\n end\n\n B --> B1\n B --> A1\n```\n\nThese deposit logs live inside historical blocks, and if the execution client node has pruned its history, the consensus client can no longer read the deposit logs it depends on. The `Eth1Data` poll mechanism would fail because the data it polls no longer exists on the node.\n\nAside from the history expiry issue, the `Eth1Data` poll flow was brittle. Consensus clients depended on JSON-RPC calls to execution clients, and inconsistencies between different execution client implementations caused failures. Block proposers needed to maintain and distribute deposit contract snapshots just to participate. The delay between a deposit transaction landing on the execution layer and the consensus layer processing it was roughly 12 hours. And the whole voting mechanism, where proposers vote on what they think the deposit contract state looks like, introduced attack surface that a direct reading would not have.\n\nNow to solve all of the above issues, [EIP-6110](https://eips.ethereum.org/EIPS/eip-6110) proposes including deposit processing as part of the execution payload sent on every block from the execution layer to the consensus layer. So when a deposit transaction is included in a block, the execution client parses the `DepositEvent` logs from that block's receipts right then, packages them into a `deposit_requests` list, and includes them in the execution payload. This kills the `Eth1Data` voting mechanism, and removes the consensus layer's dependency on historical execution layer data entirely. EIP-6110 shipped as part of the [Pectra upgrade](https://eips.ethereum.org/EIPS/eip-7600), clearing this dependency.\n\n## ERA Files\n\nOnce nodes stop serving old history, that data still needs to be retrievable somewhere. ERA files are flat-file archives containing finalized historical blocks. They are built on top of [e2store](https://github.com/status-im/nimbus-eth2/blob/stable/docs/e2store.md), a Type-Length-Value file format designed for long-term cold storage of Ethereum data. Each entry in an e2store file has an 8-byte header, followed by the data itself. The header is broken into\n\n- 2 bytes for the type\n- 4 bytes for the length\n- 2 bytes reserved\n\nThere are several [e2store formats](https://github.com/eth-clients/e2store-format-specs), and each covers its own slice of the data. ERA1 files store pre-merge execution layer history. Each ERA1 file packages 8,192 blocks worth of headers, bodies, receipts, and total difficulty values, all snappy-compressed. ERA files store post-merge beacon chain history, including beacon blocks and states, also in batches of 8,192 slots (~27 hours of chain time). E2HS files cover full execution layer history from genesis to latest, with headers accompanied by proofs of canonicalness. Erb files, still under development, are the equivalent for blob sidecars. E2SS files store execution state snapshots.\n\n```python\n # e2store entry layout\n # [type: 2 bytes | length: 4 bytes | reserved: 2 bytes | data: length bytes]\n\n # ERA1 file structure\n # era1 := Version | block-tuple* | other-entries* | Accumulator | BlockIndex\n # block-tuple := CompressedHeader | CompressedBody | CompressedReceipts | TotalDifficulty\n```\n\nThe 8,192-block batch size comes from the accumulator size limit defined in [EIP-7643](https://eips.ethereum.org/EIPS/eip-7643). Each ERA1 file includes an accumulator, which is the SSZ hash tree root of up to 8,192 header records. A header record is a pair of block hash and total difficulty. The accumulator serves as a cryptographic commitment to the contents of the file.\n\n```python\n # Header record used in the accumulator\n # header_record = { block_hash: Bytes32, total_difficulty: Uint256 }\n\n # Accumulator is the hash tree root of up to 8192 header records\n # accumulator = hash_tree_root(List[header_record], max_length=8192)\n```\n\nAnyone downloading an ERA1 file can reconstruct the epoch accumulator from the block headers inside it and compare the result against the known accumulator root. The full set of pre-merge accumulator roots is defined in EIP-7643, and the hash tree root of the entire `HistoricalHashesAccumulator` for all data before block 15,537,394 (the merge block) is a single fixed value, making it trustless.\n\n### Accumulator Verification\n\nThe accumulator works with three data structures.\n\n```python\n EPOCH_SIZE = 8192 # blocks per ERA1 file\n MAX_HISTORICAL_EPOCHS = 2048 # upper bound on pre-merge epochs\n\n # A record for a single block\n # HeaderRecord = Container[\n # block_hash: bytes32,\n # total_difficulty: uint256\n # ]\n\n # All header records within a single 8192-block epoch\n # EpochRecord = List[HeaderRecord, max_length=EPOCH_SIZE]\n\n # The top-level accumulator\n # HistoricalHashesAccumulator = Container[\n # historical_epochs: List[bytes32, max_length=MAX_HISTORICAL_EPOCHS],\n # current_epoch: EpochRecord\n # ]\n```\n\nA `HeaderRecord` pairs a block's hash with its total difficulty at that height. An `EpochRecord` collects up to 8,192 of these records. The `HistoricalHashesAccumulator` stores the Merkle roots of all completed epochs in `historical_epochs`, plus whatever partial epoch remains in `current_epoch`.\n\nFor example, if you take the first three blocks on mainnet, each block produces a `HeaderRecord`.\n\n```python\n # Block 0 (genesis)\n # header_record_0 = { block_hash: 0xd4e5..c520, total_difficulty: 17_179_869_184 }\n\n # Block 1\n # header_record_1 = { block_hash: 0x88e9..4c2d, total_difficulty: 34_359_738_368 }\n\n # Block 2\n # header_record_2 = { block_hash: 0xb495..cd62, total_difficulty: 51_539_607_552 }\n\n # ... continue for all 8192 blocks in epoch 0\n```\n\nOnce all header records for epoch 0 are collected, the epoch root is computed through SSZ Merkle tree hashing. It takes the list of 8,192 `HeaderRecords`, serializes each one as SSZ (block_hash as bytes32 + total_difficulty as uint256, giving 64 bytes per record), then builds a binary Merkle tree over the leaves. Each pair of leaves is hashed together with SHA256, then each pair of intermediate nodes is hashed again, up to the root. Since the list has a max length of 8,192, the tree is always padded to 8,192 leaves ($\\log_2(8192) = 13$ levels deep). A final \"mix in length\" step hashes the tree root with the actual list length to produce the epoch root.\n\n```python\n # epoch_root_0 = hash_tree_root([header_record_0, header_record_1, ..., header_record_8191])\n # epoch_root_0 = 0x5ec1ffb8c3b146f42606c74ced973dc16ec5a107c0345858c343fc94780b4218\n```\n\nThe root just computed is the first entry in the `historical_epochs` list. The same process repeats for every block batch across the entire pre-merge chain.\n\n```mermaid\ngraph TB\n subgraph epoch0[Epoch 0 - Blocks 0 to 8191]\n H0[HeaderRecord 0] -----> ER0[hash_tree_root]\n H2[HeaderRecord ...] -----> ER0\n H3[HeaderRecord 8191] -----> ER0\n end\n\n ER0 ----->|epoch_root_0| ACC[HistoricalHashesAccumulator]\n\n subgraph epoch1[Epoch 1 - Blocks 8192 to 16383]\n H4[HeaderRecord 8192] -----> ER1[hash_tree_root]\n H5[HeaderRecord ...] -----> ER1\n H6[HeaderRecord 16383] -----> ER1\n end\n\n ER1 ----->|epoch_root_1| ACC\n\n subgraph epoch1896[Epoch 1896 - Final partial epoch]\n H7[HeaderRecord 15532032] -----> ERN[hash_tree_root]\n H8[HeaderRecord ...] -----> ERN\n H9[HeaderRecord 15537393] -----> ERN\n end\n\n ERN ----->|current_epoch| ACC\n\n ACC ------>|hash_tree_root| ROOT[\"0xec8e040f...085e701\"]\n```\n\nThe merge happened at block 15,537,394. That means there are 1,896 complete epochs (1,896 × 8,192 = 15,531,008 blocks) plus a final partial epoch of 6,386 blocks (15,537,394 − 15,531,008). The complete epochs go into `historical_epochs` as a list of 1,896 roots. The final 6,386 header records go into `current_epoch`. The `hash_tree_root` of the entire `HistoricalHashesAccumulator` produces a single fixed value that is hardcoded into clients. It never changes because the pre-merge chain is frozen.\n\n```python\n # Final pre-merge accumulator root (from EIP-7643)\n # 0xec8e040fd6c557b41ca8ddd38f7e9d58a9281918dc92bdb72342a38fb085e701\n```\n\nWhen a node downloads an ERA1 file, verification works in four steps. Extract all block headers from the file. Build a `HeaderRecord` for each block. Compute `hash_tree_root` over the records. Compare the result against the known epoch root from EIP-7643's published table. If the roots match, the file is canonical. If they don't, the file is corrupted or tampered with and should be rejected.\n\n### Proof of Inclusion\n\nThe accumulator also enables compact Merkle proofs for individual blocks. Before EIP-7643, proving that a specific block was canonical required walking backwards through the entire parent hash chain, which is $O(n)$. With the accumulator, a Merkle proof from the leaf (the specific `HeaderRecord`) to the epoch root is $O(\\log n)$, specifically $O(\\log_2 8192) = 13$ hashes for any block within an epoch. To prove against the full accumulator root, you add one more proof step from the epoch root to the `HistoricalHashesAccumulator` root.\n\nTaking block 500,000 as an example\n\n$$\\text{epoch} = \\left\\lfloor \\frac{500{,}000}{8{,}192} \\right\\rfloor = 61$$\n\n$$\\text{position within epoch} = 500{,}000 \\mod 8{,}192 = 888$$\n\nThe Merkle proof from `HeaderRecord` at index 888 to `epoch_root_61` requires\n\n$$\\log_2(8192) = 13 \\text{ sibling hashes}$$\n\nThe Merkle proof from `epoch_root_61` to the full accumulator root requires\n\n$$\\log_2(2048) = 11 \\text{ sibling hashes}$$\n\nThe total proof size is\n\n$$13 + 11 = 24 \\text{ hashes} \\times 32 \\text{ bytes} = 768 \\text{ bytes}$$\n\nto prove any pre-merge block is canonical.\n\nThis is the verification mechanism the [Portal Network](https://www.ethportal.net/) was designed to use. When a node requests a historical block from the network, the response includes the block data plus a Merkle proof against the accumulator.\n\n### Distribution\n\nERA1 files follow the naming convention `--.era1`, for example `mainnet-00000-5ec1ffb8.era1` for the first 8,192 blocks on mainnet. The hex portion is a truncated accumulator root, so the filename itself is a quick integrity check. The BlockIndex at the end of the file stores relative offsets to each block tuple, making random access by block number possible without scanning the entire file.\n\nThe [eth-clients/history-endpoints](https://github.com/eth-clients/history-endpoints) registry maintains a community list of providers serving ERA1 and ERA files over HTTP and torrents. Providers like [ethPandaOps](https://ethpandaops.io/data/history/) host the full set of mainnet ERA1 files with SHA256 checksums for verification. Files can also be shared over [BitTorrent](magnet:?xt=urn:btih:edcc7c112bae520e3226065a61817d3575904e0d&dn=EthereumMainnetPreMergeEraFiles&xl=458498121702&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Fopen.tracker.cl%3A1337%2Fannounce&tr=udp%3A%2F%2Fbt1.archive.org%3A6969%2Fannounce). The goal is that no single provider is required and the data remains available through multiple independent channels.\n\nClient support is already in place. [Geth](https://geth.ethereum.org/docs/fundamentals/downloadera), [Nimbus](https://nimbus.guide/era-store.html), [Besu](https://besu.hyperledger.org/public-networks/how-to/era1-file-full-sync), and [Reth](https://reth.rs/docs/reth_era/index.html) all support ERA1 imports. Each etha span of 106,496 blocks is exactly 13 ERA1 files (13 × 8,192 = 106,496), so a node's storage boundaries under etha map directly to whole ERA1 files.\n\n## Portal Network\n\nERA files solve the archival problem but they are static. A node that needs a single old block should not have to download an entire 8,192-block file to get it. The [Portal Network](https://www.ethportal.net/) provides the on-demand retrieval layer. It is a lightweight peer-to-peer network where each participating node stores a small slice of Ethereum's data and serves it when requested. Unlike the existing DevP2P network where every full node is expected to hold everything, Portal is designed so that every node that joins adds capacity rather than consuming it.\n\nPortal runs on top of [Discovery v5](https://github.com/ethereum/devp2p/blob/master/discv5/discv5.md) over UDP and is split into independent sub-networks for history, beacon chain data, and state. Each sub-network forms its own overlay DHT. Data enters through bridge nodes that pull from full nodes over JSON-RPC and push into the appropriate sub-network. Every piece of data is identified by a content key and each node stores content based on its XOR distance to that key, controlled by a self-declared radius. Retrieval is verified using accumulator proofs for pre-merge data and beacon chain `historical_summaries` for post-merge data.\n\nHowever, Portal Network development has largely stalled and it is not currently an active part of\nthe history expiry roadmap. Four client implementations exist ([Trin](https://github.com/ethereum/trin),\n[Fluffy](https://github.com/status-im/nimbus-eth1/tree/master/fluffy),\n[Ultralight](https://github.com/ethereumjs/ultralight),\n[Shisui](https://github.com/optimism-java/shisui)) although active work has slowed down significantly.\n\n\n## Current Status\n\nPhase 1 of history expiry is already underway with EIP-6110 shipped as part of the Pectra upgrade. Phase 1 targets pre-Merge (PoW) history, which accounts for the bulk of stored data on most nodes. Phase 2 covers post-Merge history with non-contiguous sharding through etha (EIP-7801) and is still in active development.\n\n\n## Resources\n\n- [EIP-4444: Bound Historical Data in Execution Clients](https://eips.ethereum.org/EIPS/eip-4444), [archived](https://web.archive.org/web/20240601000000*/https://eips.ethereum.org/EIPS/eip-4444)\n- [EIP-6110: Supply validator deposits on chain](https://eips.ethereum.org/EIPS/eip-6110), [archived](https://web.archive.org/web/20240601000000*/https://eips.ethereum.org/EIPS/eip-6110)\n- [EIP-7642: eth/69 - history expiry and simpler receipts](https://eips.ethereum.org/EIPS/eip-7642), [archived](https://web.archive.org/web/20240601000000*/https://eips.ethereum.org/EIPS/eip-7642)\n- [EIP-7643: History accumulator for pre-PoS data](https://eips.ethereum.org/EIPS/eip-7643), [archived](https://web.archive.org/web/20240601000000*/https://eips.ethereum.org/EIPS/eip-7643)\n- [EIP-7801: etha - Sharded Blocks Subprotocol](https://eips.ethereum.org/EIPS/eip-7801), [archived](https://web.archive.org/web/20240601000000*/https://eips.ethereum.org/EIPS/eip-7801)\n- [e2store format specifications](https://github.com/eth-clients/e2store-format-specs)\n- [ERA1 format specification](https://github.com/eth-clients/e2store-format-specs/blob/main/formats/era1.md)\n- [Ethereum historical data endpoints](https://eth-clients.github.io/history-endpoints/)\n- [Portal Network specifications](https://github.com/ethereum/portal-network-specs)\n- [Portal Network design requirements](https://blog.ethportal.net/posts/design-requirements-for-portal-network)\n- [Portal Network FAQ](https://notes.ethereum.org/@Kolby-ML/HJ-9D5aYp)\n- [ethPandaOps ERA1 data](https://ethpandaops.io/data/history/)\n- [Nimbus ERA store guide](https://nimbus.guide/era-store.html)\n- [Geth ERA download guide](https://geth.ethereum.org/docs/fundamentals/downloadera)\n- [Besu ERA1 import guide](https://besu.hyperledger.org/public-networks/how-to/era1-file-full-sync)\n- [The Portal Network on ethereum.org](https://ethereum.org/developers/docs/networking-layer/portal-network/)" }, { "path": "docs/wiki/research/img/scaling/layer-1-scaling.excalidraw", "content": "{\n \"type\": \"excalidraw\",\n \"version\": 2,\n \"source\": \"https://excalidraw.com\",\n \"elements\": [\n {\n \"type\": \"line\",\n \"version\": 184,\n \"versionNonce\": 1660740357,\n \"isDeleted\": false,\n \"id\": \"WNxPCMGMatY2MXVSHf70T\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -161.0650900251764,\n \"y\": -95.1792827465772,\n \"strokeColor\": \"#1971c2\",\n \"backgroundColor\": \"transparent\",\n \"width\": 309.6428571428572,\n \"height\": 256.42857142857133,\n \"seed\": 1431157323,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1708368604973,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 309.6428571428572,\n -256.42857142857133\n ]\n ]\n },\n {\n \"type\": \"line\",\n \"version\": 307,\n \"versionNonce\": 33192907,\n \"isDeleted\": false,\n \"id\": \"veMhJeqljPvK6e16nggLZ\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -163.5479958316186,\n \"y\": -93.14213214568736,\n \"strokeColor\": \"#1971c2\",\n \"backgroundColor\": \"transparent\",\n \"width\": 596.4285714285713,\n \"height\": 8.571428571428669,\n \"seed\": 1205221611,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1708368604973,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 596.4285714285713,\n 8.571428571428669\n ]\n ]\n },\n {\n \"type\": \"line\",\n \"version\": 472,\n \"versionNonce\": 232012389,\n \"isDeleted\": false,\n \"id\": \"dcY33BUr_6UH1de8iBn99\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 155.944591598518,\n \"y\": -354.1900063102689,\n \"strokeColor\": \"#1971c2\",\n \"backgroundColor\": \"transparent\",\n \"width\": 585.0396825396825,\n \"height\": 14.821428571428669,\n \"seed\": 1578492811,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1708368604973,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 585.0396825396825,\n 14.821428571428669\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 927,\n \"versionNonce\": 342805099,\n \"isDeleted\": false,\n \"id\": \"LomAgkKqvAbaE3EVlCOJo\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0.033315017793863255,\n \"x\": 78.16288249065548,\n \"y\": -239.4362770430581,\n \"strokeColor\": \"#1971c2\",\n \"backgroundColor\": \"transparent\",\n \"width\": 422.8500061035156,\n \"height\": 25,\n \"seed\": 1883716139,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [],\n \"updated\": 1708368604974,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 20,\n \"fontFamily\": 1,\n \"text\": \"Ethereum L1 resources surface (gas limits)\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Ethereum L1 resources surface (gas limits)\",\n \"lineHeight\": 1.25,\n \"baseline\": 18\n },\n {\n \"type\": \"line\",\n \"version\": 284,\n \"versionNonce\": 990518085,\n \"isDeleted\": false,\n \"id\": \"NwEMub6Tvo3MxT3rZe6kU\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 431.375948239092,\n \"y\": -79.48075201962092,\n \"strokeColor\": \"#1971c2\",\n \"backgroundColor\": \"transparent\",\n \"width\": 309.6428571428572,\n \"height\": 256.42857142857133,\n \"seed\": 730005963,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1708368604974,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 309.6428571428572,\n -256.42857142857133\n ]\n ]\n },\n {\n \"id\": \"dwNtlR72sgm02Eha4v06A\",\n \"type\": \"arrow\",\n \"x\": 421.5683750203991,\n \"y\": -358.05271197071875,\n \"width\": 56.28983675456129,\n \"height\": 46.35633615081497,\n \"angle\": 0,\n \"strokeColor\": \"#e03131\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"seed\": 287393611,\n \"version\": 65,\n \"versionNonce\": 1434283883,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1708368604974,\n \"link\": null,\n \"locked\": false,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 56.28983675456129,\n -46.35633615081497\n ]\n ],\n \"lastCommittedPoint\": null,\n \"startBinding\": null,\n \"endBinding\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\"\n },\n {\n \"type\": \"arrow\",\n \"version\": 209,\n \"versionNonce\": 1591988421,\n \"isDeleted\": false,\n \"id\": \"ZmP80g-RC_q8SDeiyP8RC\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 132.8168574978846,\n \"y\": -78.63365281079416,\n \"strokeColor\": \"#e03131\",\n \"backgroundColor\": \"transparent\",\n \"width\": 54.63425332060308,\n \"height\": 54.63425332060365,\n \"seed\": 4860459,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1708368604974,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -54.63425332060308,\n 54.63425332060365\n ]\n ]\n },\n {\n \"type\": \"arrow\",\n \"version\": 312,\n \"versionNonce\": 1318210059,\n \"isDeleted\": false,\n \"id\": \"B2xFb63cnymvcYr3pN_-0\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 13.549571368834819,\n \"y\": -253.7368778054468,\n \"strokeColor\": \"#e03131\",\n \"backgroundColor\": \"transparent\",\n \"width\": 92.71267230162971,\n \"height\": 2.2737367544323206e-13,\n \"seed\": 162362725,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1708368604974,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -92.71267230162971,\n 2.2737367544323206e-13\n ]\n ]\n },\n {\n \"type\": \"arrow\",\n \"version\": 419,\n \"versionNonce\": 1377267749,\n \"isDeleted\": false,\n \"id\": \"iT79E2EFXsHTSL2M9rCpt\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 639.8652815301908,\n \"y\": -240.85424470040562,\n \"strokeColor\": \"#e03131\",\n \"backgroundColor\": \"transparent\",\n \"width\": 87.74592199975723,\n \"height\": 1.655583433957986,\n \"seed\": 225583211,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1708368604974,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\",\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 87.74592199975723,\n 1.655583433957986\n ]\n ]\n },\n {\n \"type\": \"line\",\n \"version\": 779,\n \"versionNonce\": 1070170955,\n \"isDeleted\": false,\n \"id\": \"fqRfzolsvE1v5MSFrjxh4\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -5.266685440267565,\n \"y\": -357.93970578751146,\n \"strokeColor\": \"#e03131\",\n \"backgroundColor\": \"transparent\",\n \"width\": 156.4824324257089,\n \"height\": 4.901121855827455,\n \"seed\": 313127333,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1708368604974,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 156.4824324257089,\n 4.901121855827455\n ]\n ]\n },\n {\n \"type\": \"line\",\n \"version\": 834,\n \"versionNonce\": 503016165,\n \"isDeleted\": false,\n \"id\": \"Nh6TtRECGXh9MriJV4l4Z\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -314.0576081704258,\n \"y\": -99.12745584473362,\n \"strokeColor\": \"#e03131\",\n \"backgroundColor\": \"transparent\",\n \"width\": 156.4824324257089,\n \"height\": 4.901121855827455,\n \"seed\": 417511339,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1708368604974,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 156.4824324257089,\n 4.901121855827455\n ]\n ]\n },\n {\n \"type\": \"line\",\n \"version\": 832,\n \"versionNonce\": 1643176427,\n \"isDeleted\": false,\n \"id\": \"mVCGMkECtWGKM68NsBXLP\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 427.98133415654735,\n \"y\": -87.223087786012,\n \"strokeColor\": \"#e03131\",\n \"backgroundColor\": \"transparent\",\n \"width\": 156.4824324257089,\n \"height\": 4.901121855827455,\n \"seed\": 1037531819,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1708368604974,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 156.4824324257089,\n 4.901121855827455\n ]\n ]\n },\n {\n \"type\": \"line\",\n \"version\": 833,\n \"versionNonce\": 460768837,\n \"isDeleted\": false,\n \"id\": \"5ufvQ2iLLYHGbOcNvsDWO\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 739.4789650264265,\n \"y\": -333.24669433292297,\n \"strokeColor\": \"#e03131\",\n \"backgroundColor\": \"transparent\",\n \"width\": 156.4824324257089,\n \"height\": 4.901121855827455,\n \"seed\": 1924734059,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1708368604974,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 156.4824324257089,\n 4.901121855827455\n ]\n ]\n },\n {\n \"type\": \"line\",\n \"version\": 1132,\n \"versionNonce\": 284388491,\n \"isDeleted\": false,\n \"id\": \"64djqob5Xe9zKL28R9iU9\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 140.74512258715754,\n \"y\": -348.0343347390927,\n \"strokeColor\": \"#e03131\",\n \"backgroundColor\": \"transparent\",\n \"width\": 125.00617388335138,\n \"height\": 103.22218758381428,\n \"seed\": 549852837,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1708368604974,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 125.00617388335138,\n -103.22218758381428\n ]\n ]\n },\n {\n \"type\": \"line\",\n \"version\": 1172,\n \"versionNonce\": 1619764011,\n \"isDeleted\": false,\n \"id\": \"i6_ByUS9BvWA9w-VuS2qv\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 739.2270729895911,\n \"y\": -334.1869867347167,\n \"strokeColor\": \"#e03131\",\n \"backgroundColor\": \"transparent\",\n \"width\": 125.00617388335138,\n \"height\": 103.22218758381428,\n \"seed\": 1032821893,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1708368604974,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 125.00617388335138,\n -103.22218758381428\n ]\n ]\n },\n {\n \"type\": \"line\",\n \"version\": 1165,\n \"versionNonce\": 2043918597,\n \"isDeleted\": false,\n \"id\": \"WbvfaWuPzuOJ267ILSWSF\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 307.2666322897528,\n \"y\": 19.235192019696683,\n \"strokeColor\": \"#e03131\",\n \"backgroundColor\": \"transparent\",\n \"width\": 125.00617388335138,\n \"height\": 103.22218758381428,\n \"seed\": 2002018597,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1708368604974,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 125.00617388335138,\n -103.22218758381428\n ]\n ]\n },\n {\n \"type\": \"line\",\n \"version\": 1183,\n \"versionNonce\": 153355723,\n \"isDeleted\": false,\n \"id\": \"kP2tJE-v3tN3ALfWaCceU\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -278.7496299184198,\n \"y\": 2.6213289158566795,\n \"strokeColor\": \"#e03131\",\n \"backgroundColor\": \"transparent\",\n \"width\": 125.00617388335138,\n \"height\": 103.22218758381428,\n \"seed\": 732098085,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1708368604974,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 125.00617388335138,\n -103.22218758381428\n ]\n ]\n },\n {\n \"type\": \"line\",\n \"version\": 405,\n \"versionNonce\": 2085050763,\n \"isDeleted\": false,\n \"id\": \"qr6J-VbrrnqvbJjJkcl0W\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -431.7781496014154,\n \"y\": -0.34599481986981573,\n \"strokeColor\": \"#e03131\",\n \"backgroundColor\": \"transparent\",\n \"width\": 552.0158618377128,\n \"height\": 453.3566377431414,\n \"seed\": 1189020683,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1708368664125,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 552.0158618377128,\n -453.3566377431414\n ]\n ]\n },\n {\n \"type\": \"line\",\n \"version\": 571,\n \"versionNonce\": 1260260395,\n \"isDeleted\": false,\n \"id\": \"Yli_CgyDA-LB3BmEKElhN\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 116.18697214512036,\n \"y\": -454.50602228047524,\n \"strokeColor\": \"#e03131\",\n \"backgroundColor\": \"transparent\",\n \"width\": 890.1699830930274,\n \"height\": 29.9697413648571,\n \"seed\": 1647917861,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1708368652355,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 890.1699830930274,\n 29.9697413648571\n ]\n ]\n },\n {\n \"type\": \"line\",\n \"version\": 524,\n \"versionNonce\": 1687060427,\n \"isDeleted\": false,\n \"id\": \"At0RkXV-ZDlVr78LO8LMM\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 465.4507050840871,\n \"y\": 24.480639468530853,\n \"strokeColor\": \"#e03131\",\n \"backgroundColor\": \"transparent\",\n \"width\": 539.0315937290599,\n \"height\": 444.70045900403943,\n \"seed\": 2008918981,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1708368650067,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 539.0315937290599,\n -444.70045900403943\n ]\n ]\n },\n {\n \"type\": \"line\",\n \"version\": 717,\n \"versionNonce\": 1955072971,\n \"isDeleted\": false,\n \"id\": \"W-_qAxEbimxSxGO_PNMLx\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -431.20341611761967,\n \"y\": -7.282140670570243,\n \"strokeColor\": \"#e03131\",\n \"backgroundColor\": \"transparent\",\n \"width\": 894.4980724625783,\n \"height\": 29.9697413648571,\n \"seed\": 1447393579,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1708368667884,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 894.4980724625783,\n 29.9697413648571\n ]\n ]\n },\n {\n \"id\": \"6qalYRhqDMcSI1NEOGaYM\",\n \"type\": \"text\",\n \"x\": 357.9729831892024,\n \"y\": -591.65468130435,\n \"width\": 142.88333129882812,\n \"height\": 25,\n \"angle\": 0,\n \"strokeColor\": \"#e03131\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"seed\": 889836811,\n \"version\": 105,\n \"versionNonce\": 2119323467,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1708368692515,\n \"link\": null,\n \"locked\": false,\n \"text\": \"Layer 1 scaling\",\n \"fontSize\": 20,\n \"fontFamily\": 1,\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"baseline\": 18,\n \"containerId\": null,\n \"originalText\": \"Layer 1 scaling\",\n \"lineHeight\": 1.25\n }\n ],\n \"appState\": {\n \"gridSize\": null,\n \"viewBackgroundColor\": \"#ffffff\"\n },\n \"files\": {}\n}" }, { "path": "docs/wiki/research/img/scaling/layer-2-scaling.excalidraw", "content": "{\n \"type\": \"excalidraw\",\n \"version\": 2,\n \"source\": \"https://excalidraw.com\",\n \"elements\": [\n {\n \"type\": \"line\",\n \"version\": 184,\n \"versionNonce\": 1660740357,\n \"isDeleted\": false,\n \"id\": \"WNxPCMGMatY2MXVSHf70T\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -161.0650900251764,\n \"y\": -95.1792827465772,\n \"strokeColor\": \"#1971c2\",\n \"backgroundColor\": \"transparent\",\n \"width\": 309.6428571428572,\n \"height\": 256.42857142857133,\n \"seed\": 1431157323,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1708368604973,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 309.6428571428572,\n -256.42857142857133\n ]\n ]\n },\n {\n \"type\": \"line\",\n \"version\": 307,\n \"versionNonce\": 33192907,\n \"isDeleted\": false,\n \"id\": \"veMhJeqljPvK6e16nggLZ\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -163.5479958316186,\n \"y\": -93.14213214568736,\n \"strokeColor\": \"#1971c2\",\n \"backgroundColor\": \"transparent\",\n \"width\": 596.4285714285713,\n \"height\": 8.571428571428669,\n \"seed\": 1205221611,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1708368604973,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 596.4285714285713,\n 8.571428571428669\n ]\n ]\n },\n {\n \"type\": \"line\",\n \"version\": 472,\n \"versionNonce\": 232012389,\n \"isDeleted\": false,\n \"id\": \"dcY33BUr_6UH1de8iBn99\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 155.944591598518,\n \"y\": -354.1900063102689,\n \"strokeColor\": \"#1971c2\",\n \"backgroundColor\": \"transparent\",\n \"width\": 585.0396825396825,\n \"height\": 14.821428571428669,\n \"seed\": 1578492811,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1708368604973,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 585.0396825396825,\n 14.821428571428669\n ]\n ]\n },\n {\n \"type\": \"text\",\n \"version\": 928,\n \"versionNonce\": 1121534053,\n \"isDeleted\": false,\n \"id\": \"LomAgkKqvAbaE3EVlCOJo\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0.033315017793863255,\n \"x\": 78.16288249065548,\n \"y\": -239.4362770430581,\n \"strokeColor\": \"#1971c2\",\n \"backgroundColor\": \"transparent\",\n \"width\": 422.8500061035156,\n \"height\": 25,\n \"seed\": 1883716139,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"boundElements\": [\n {\n \"id\": \"CAGn8t0qePxXo8kdHpCwd\",\n \"type\": \"arrow\"\n }\n ],\n \"updated\": 1708368968557,\n \"link\": null,\n \"locked\": false,\n \"fontSize\": 20,\n \"fontFamily\": 1,\n \"text\": \"Ethereum L1 resources surface (gas limits)\",\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"containerId\": null,\n \"originalText\": \"Ethereum L1 resources surface (gas limits)\",\n \"lineHeight\": 1.25,\n \"baseline\": 18\n },\n {\n \"type\": \"line\",\n \"version\": 284,\n \"versionNonce\": 990518085,\n \"isDeleted\": false,\n \"id\": \"NwEMub6Tvo3MxT3rZe6kU\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 431.375948239092,\n \"y\": -79.48075201962092,\n \"strokeColor\": \"#1971c2\",\n \"backgroundColor\": \"transparent\",\n \"width\": 309.6428571428572,\n \"height\": 256.42857142857133,\n \"seed\": 730005963,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1708368604974,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 309.6428571428572,\n -256.42857142857133\n ]\n ]\n },\n {\n \"id\": \"6qalYRhqDMcSI1NEOGaYM\",\n \"type\": \"text\",\n \"x\": 824.6396498558689,\n \"y\": -564.9880146376834,\n \"width\": 151.6666717529297,\n \"height\": 25,\n \"angle\": 0,\n \"strokeColor\": \"#e03131\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": null,\n \"seed\": 889836811,\n \"version\": 162,\n \"versionNonce\": 1573104517,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1708368936342,\n \"link\": null,\n \"locked\": false,\n \"text\": \"Layer 2 scaling\",\n \"fontSize\": 20,\n \"fontFamily\": 1,\n \"textAlign\": \"left\",\n \"verticalAlign\": \"top\",\n \"baseline\": 18,\n \"containerId\": null,\n \"originalText\": \"Layer 2 scaling\",\n \"lineHeight\": 1.25\n },\n {\n \"type\": \"line\",\n \"version\": 273,\n \"versionNonce\": 326082219,\n \"isDeleted\": false,\n \"id\": \"O1FO4JYTWAdrw5usnrWyF\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -171.02979542824295,\n \"y\": -540.3038487500635,\n \"strokeColor\": \"#e03131\",\n \"backgroundColor\": \"transparent\",\n \"width\": 309.6428571428572,\n \"height\": 256.42857142857133,\n \"seed\": 1893311653,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1708368951438,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 309.6428571428572,\n -256.42857142857133\n ]\n ]\n },\n {\n \"type\": \"line\",\n \"version\": 396,\n \"versionNonce\": 1407137157,\n \"isDeleted\": false,\n \"id\": \"duVngYueFfOXqmTXBp3RZ\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -173.51270123468515,\n \"y\": -538.2666981491736,\n \"strokeColor\": \"#e03131\",\n \"backgroundColor\": \"transparent\",\n \"width\": 596.4285714285713,\n \"height\": 8.571428571428669,\n \"seed\": 1911015429,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1708368951438,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 596.4285714285713,\n 8.571428571428669\n ]\n ]\n },\n {\n \"type\": \"line\",\n \"version\": 561,\n \"versionNonce\": 1157402955,\n \"isDeleted\": false,\n \"id\": \"xNTcFxGybV7dM1WbDJFjl\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 145.9798861954514,\n \"y\": -799.3145723137552,\n \"strokeColor\": \"#e03131\",\n \"backgroundColor\": \"transparent\",\n \"width\": 585.0396825396825,\n \"height\": 14.821428571428669,\n \"seed\": 672825189,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1708368951438,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 585.0396825396825,\n 14.821428571428669\n ]\n ]\n },\n {\n \"type\": \"line\",\n \"version\": 373,\n \"versionNonce\": 63454437,\n \"isDeleted\": false,\n \"id\": \"-MQ_8CjOXeV88XeYR9I7b\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 2,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 421.4112428360254,\n \"y\": -524.6053180231072,\n \"strokeColor\": \"#e03131\",\n \"backgroundColor\": \"transparent\",\n \"width\": 309.6428571428572,\n \"height\": 256.42857142857133,\n \"seed\": 1735633445,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1708368951438,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n 309.6428571428572,\n -256.42857142857133\n ]\n ]\n },\n {\n \"id\": \"CAGn8t0qePxXo8kdHpCwd\",\n \"type\": \"arrow\",\n \"x\": 293.3063165225359,\n \"y\": -254.98801463768336,\n \"width\": 3.3333333333332575,\n \"height\": 208.33333333333337,\n \"angle\": 0,\n \"strokeColor\": \"#e03131\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"solid\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"seed\": 333011013,\n \"version\": 209,\n \"versionNonce\": 1705683205,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1708368968557,\n \"link\": null,\n \"locked\": false,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -3.3333333333332575,\n -208.33333333333337\n ]\n ],\n \"lastCommittedPoint\": null,\n \"startBinding\": {\n \"elementId\": \"LomAgkKqvAbaE3EVlCOJo\",\n \"focus\": 0.01967439709361112,\n \"gap\": 15.660028537192602\n },\n \"endBinding\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": \"arrow\"\n },\n {\n \"id\": \"s99SV9GDd_5XKneWO1qhh\",\n \"type\": \"line\",\n \"x\": 433.30631652253624,\n \"y\": -88.32134797101662,\n \"width\": 15,\n \"height\": 440.0000000000001,\n \"angle\": 0,\n \"strokeColor\": \"#e03131\",\n \"backgroundColor\": \"transparent\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"seed\": 1614162725,\n \"version\": 86,\n \"versionNonce\": 1701284395,\n \"isDeleted\": false,\n \"boundElements\": null,\n \"updated\": 1708368977221,\n \"link\": null,\n \"locked\": false,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -15,\n -440.0000000000001\n ]\n ],\n \"lastCommittedPoint\": null,\n \"startBinding\": null,\n \"endBinding\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null\n },\n {\n \"type\": \"line\",\n \"version\": 131,\n \"versionNonce\": 32379205,\n \"isDeleted\": false,\n \"id\": \"TGYcXhawQAISjl8MMAumk\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 738.410471349361,\n \"y\": -339.76370230801854,\n \"strokeColor\": \"#e03131\",\n \"backgroundColor\": \"transparent\",\n \"width\": 10,\n \"height\": 440.0000000000001,\n \"seed\": 431044965,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1708368982365,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -10,\n -440.0000000000001\n ]\n ]\n },\n {\n \"type\": \"line\",\n \"version\": 209,\n \"versionNonce\": 1178622539,\n \"isDeleted\": false,\n \"id\": \"CjNgxblSQ1ClPFBeQ0E8w\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": -161.99339776297177,\n \"y\": -100.29629038461007,\n \"strokeColor\": \"#e03131\",\n \"backgroundColor\": \"transparent\",\n \"width\": 10,\n \"height\": 440.0000000000001,\n \"seed\": 1243473963,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1708368986232,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -10,\n -440.0000000000001\n ]\n ]\n },\n {\n \"type\": \"line\",\n \"version\": 282,\n \"versionNonce\": 1815359627,\n \"isDeleted\": false,\n \"id\": \"1A-LYGQw2543WJ1kB0uwg\",\n \"fillStyle\": \"solid\",\n \"strokeWidth\": 1,\n \"strokeStyle\": \"dashed\",\n \"roughness\": 1,\n \"opacity\": 100,\n \"angle\": 0,\n \"x\": 149.3956788024828,\n \"y\": -350.64806600176246,\n \"strokeColor\": \"#e03131\",\n \"backgroundColor\": \"transparent\",\n \"width\": 10,\n \"height\": 440.0000000000001,\n \"seed\": 1793098635,\n \"groupIds\": [],\n \"frameId\": null,\n \"roundness\": {\n \"type\": 2\n },\n \"boundElements\": [],\n \"updated\": 1708368991587,\n \"link\": null,\n \"locked\": false,\n \"startBinding\": null,\n \"endBinding\": null,\n \"lastCommittedPoint\": null,\n \"startArrowhead\": null,\n \"endArrowhead\": null,\n \"points\": [\n [\n 0,\n 0\n ],\n [\n -10,\n -440.0000000000001\n ]\n ]\n }\n ],\n \"appState\": {\n \"gridSize\": null,\n \"viewBackgroundColor\": \"#ffffff\"\n },\n \"files\": {}\n}" }, { "path": "docs/wiki/research/light-clients.md", "content": "# Light Clients\n\n> :warning: This article is a [stub](https://en.wikipedia.org/wiki/Wikipedia:Stub), help the wiki by [contributing](/contributing.md) and expanding it.\n\nEthereum users are connecting to the network using an execution client RPC. This allows them to interact with the network, read balances, submit transactions, etc. Running the client and verifying the current state can be a demanding task requiring hundreds of GBs storage space, bandwidth and computation. Most wallets default to using a third party API to connect to the network without verifying the provided data. \n\nThe idea of a light client is to enable trustless access to the network without overhead of running a full node. Light client is a general term for this concept but the actual approach is using different designs. There are multiple kinds of light clients, some in production, some still being researched and developed. \n\n- Verifying EL RPC data using Beacon root from a CL client\n- Stateless clients\n- LES protocol\n- Portal network\n\n## RPC proxy light client \n\nThis sort of light clients connect to an RPC provider and improves the security by verifying responses using a proof from an independent Beacon Node. It's basically an RPC proxy or a middleware which ensures that data from the provider are valid. \nIt improves the trust model of a wallet/service connected to a third party RPC but doesn't act as a node in the network. With this light client approach, users still need to connect to some RPC provider, a centralized entity.\n\nClients communicating in the network over p2p protocol don't have specific functions for specific pieces of data like with RPC. They can get current tip from the peer, request historical blocks, etc. And to verify them, they also need connection to a consensus client. There is no way to request balance of an address over p2p, only download blocks/state, verify and find it yourself. With this approach, we basically arrive at the behavior of a normal node in the network. \n\nThe implementation of the RPC verifying 'light client' is for example [Helios](https://github.com/a16z/helios) or [Kevlar](https://github.com/lightclients/kevlar). User can run them as a proxy between an app/wallet and their rpc provider. They offer a default connection to a public beacon node so the chance that both of these providers lie in the same exact way is minimal. There was a [project trying to implement the CL p2p in Helios](ttps://github.com/eth-protocol-fellows/cohort-three/blob/master/projects/helios-cl-p2p.md) in order to use it directly with cl libp2p instead of relying on a third party Beacon API. \n\n## Stateless clients\n\nUsing witnesses gossiped over p2p network to verify the data without full state.\n\n## Portal Network\n\nPortal creates an overlay network which guarantees data integrity probabilistically. \n\n## LES\n\nLight client mode pioneered by Geth enables to run a node in light config which subscribes to les p2p protocol. The node doesn't download the entire chain, only downloads the latest data from other nodes serving les. The full node needs to be configured to provide les data, it's not a default option. Therefore there are not enough les providers in the network to enable using geth in light mode reliable. " }, { "path": "docs/wiki/research/peerdas.md", "content": "# Introduction to Ethereum PeerDAS\n\n> :warning: This article is a [stub](https://en.wikipedia.org/wiki/Wikipedia:Stub), help the wiki by [contributing](/contributing.md) and expanding it.\n\n> :warning: This document covers an active area of research. It may be outdated at the time of reading and is subject to future updates as the design space evolves.\n\n**PeerDAS** (Peer Data Availability Sampling) is a networking protocol introduced in [EIP-7594](https://eips.ethereum.org/EIPS/eip-7594). It is designed to optimize data distribution and verification across Ethereum's network. PeerDAS ensures that blobs, mainly containing data from Layer 2 (L2) solutions like rollups, remain reliably accessible without overwhelming nodes.\n\n## PeerDAS in the Ethereum Roadmap\n\nScaling is essential for Ethereum. The network must increase its capacity to process more transactions and store data, making transactions cheaper and more accessible to users. As demand for blockchain applications grows, Ethereum needs to support higher throughput without compromising decentralization or security.\n\nPeerDAS is a critical component of [Danksharding](https://ethereum.org/en/roadmap/danksharding/) and plays a key role in Ethereum's rollup-centric roadmap. It is part of the [Surge](https://vitalik.eth.limo/general/2024/10/17/futures2.html) roadmap category, which focuses on scaling transaction throughput and reducing costs.\n\nLayer 2 (L2) solutions, such as rollups, rely on Ethereum for data availability and security. Initially, rollups posted their transaction data directly to Ethereum execution layer as calldata, a method that was both expensive and inefficient. [EIP-4844 (Proto-Danksharding)](https://eips.ethereum.org/EIPS/eip-4844) introduced **blobs**—a new data structure that allows rollups to post data at a significantly lower cost. While EIP-4844 was an important improvement, it is only a stepping stone toward Danksharding. In Danksharding, blobs will be transformed into **data columns** and distributed across the network using PeerDAS. This transformation will further reduce costs and improve scalability.\n\nEthereum researchers have outlined a gradual, multi-stage roadmap for PeerDAS that balances increased throughput with network robustness:\n\n- **Stage 0 (EIP-4844):** Introduces subnets for blob distribution without Data Availability Sampling (DAS), requiring nodes to download all data.\n- **Stage 1:** Implements 1D PeerDAS by horizontally extending blobs and introducing column subnets, enabling peer sampling for improved efficiency.\n- **Stage 2:** Completes Danksharding with 2D PeerDAS by adding vertical blob extensions and lightweight, cell-based peer sampling, supporting robust distributed reconstruction and maximizing scalability.\n\n## Understanding PeerDAS\n\n### Data Partitioning and Custody Assignment\n\nPeerDAS divides data blobs into smaller units called *columns*, which serve as the atomic components for data sampling. The network assigns nodes to custody groups responsible for specific sets of columns. A deterministic function, using publicly verifiable inputs such as node IDs, governs this assignment to ensure transparent and reproducible distribution. Nodes must maintain a minimum custody threshold to guarantee baseline data availability. Those that store additional columns become **super-nodes**, holding all columns and increasing system redundancy to enhance fault tolerance.\n\n### Data Encoding and Distribution\n\nData blobs are encoded using Reed-Solomon erasure codes. This process divides the data into multiple columns and adds parity columns, enabling the reconstruction of the original dataset even if some columns are missing. Once encoded, each column is disseminated across the network using a gossip protocol. Proposers initially distribute columns to a subset of nodes, which then relay the data to their peers. Nodes subscribe to subnets aligned with their custody groups, optimizing data flow and minimizing network congestion. If a node does not receive a column via gossip, it can retrieve the missing data using a request/response protocol with other nodes.\n\n### Data Availability Sampling (DAS)\n\nPeerDAS employs Data Availability Sampling to verify data without requiring a full download. Nodes request random samples of columns from their peers. By using probabilistic methods, a node infers the availability of the complete dataset when it obtains a sufficient number of samples. If missing columns are detected, the node can initiate direct requests to recover the data.\n\n### Cryptographic Verification with KZG Commitments\n\nTo ensure data integrity and authenticity, PeerDAS uses KZG (Kate-Zaverucha-Goldberg) commitments. These cryptographic commitments enable nodes to verify that the sampled columns match the original dataset without needing to download the full data. This efficient verification process prevents tampering and data corruption.\n\n### Data Reconstruction and Redundancy Management\n\nNodes continuously sample the columns under their custody. When a node accumulates more than 50% of the total columns for a data blob, it can fully reconstruct the original dataset using Reed-Solomon decoding. Once reconstructed, the node redistributes the recovered columns back into the network. This redistribution enhances overall data availability and resilience against subnet failures or temporary data unavailability.\n\n### Validator Protocols and Fork-Choice Rules\n\nValidators follow modified fork-choice rules to enforce data availability during the consensus process. For newly proposed blocks, validators assess data availability based on columns received via gossip subnets. For older blocks, they rely on peer sampling results to verify ongoing data availability. This dual approach mitigates risks associated with temporary data withholding, ensuring that validators vote only for blocks with verifiable data and thereby maintaining the blockchain's integrity and security.\n\nOverall, PeerDAS integrates deterministic custody allocation, probabilistic data availability sampling, robust erasure coding, and cryptographic commitments to provide a scalable, fault-tolerant, and secure framework for data availability in decentralized networks. Its design ensures that data remains verifiable and recoverable even under adversarial conditions, making it a resilient architecture for distributed data management.\n\n## References\n\n- [EIP-7594: PeerDAS](https://eips.ethereum.org/EIPS/eip-7594)\n- [Fulu specifications including PeerDAS](https://github.com/ethereum/consensus-specs/tree/dev/specs/fulu)\n- [Scaling Ethereum L1 with PeerDAS - dapplion, presentation](https://www.youtube.com/watch?v=_PW6jFTWLPc)\n- [PeerDAS in Pectra and beyond - Francesco D'Amato, presentation](https://www.youtube.com/watch?v=WOdpO1tH_Us)\n- [PeerDAS Book by Manu Nalepa](https://hackmd.io/@manunalepa/peerDAS/https%3A%2F%2Fhackmd.io%2F%40manunalepa%2FB1idHCOfke)\n- [Possible futures of the Ethereum protocol, part 2: The Surge by Vitalik Buterin](https://vitalik.eth.limo/general/2024/10/17/futures2.html)\n- [From 4844 to Danksharding: a path to scaling Ethereum DA (ethresear.ch)](https://ethresear.ch/t/from-4844-to-danksharding-a-path-to-scaling-ethereum-da/18046)\n- [PeerDAS – a simpler DAS approach using battle-tested p2p components (ethresear.ch)](https://ethresear.ch/t/peerdas-a-simpler-das-approach-using-battle-tested-p2p-components/16541)\n- [DevCon Sea: Scaling Ethereum with DAS by Francesco](https://www.youtube.com/watch?v=toR2UKzE_zA)\n- [DevCon Sea: From PeerDAS to FullDAS](https://www.youtube.com/watch?v=Y8VKmyJMAUk&t=9s)\n- [EthPrague: PeerDAS by Dapplion](https://www.youtube.com/watch?v=fCIPNxGXmmE&t=43s)\n- [PeerDAS in Pectra and beyond by Francesco](https://www.youtube.com/watch?v=WOdpO1tH_Us&t=334s)\n" }, { "path": "docs/wiki/research/roadmap.md", "content": "# Ethereum Protocol Roadmap \n\nThe development philosophy of Ethereum is open to protocol evolution and certain risk aversion for benefits which are worth the change. As our knowledge and experience of Ethereum grows, researchers and developers are crafting ideas on how to tackle challenges and limitations of the network. There has been [many changes](/wiki/protocol/history.md) to the core protocol over many years of its existence. Most of these changes are part of some common goals we could call a roadmap. \n\nEven though there is no official roadmap and no authority which could dictate it, there are wide community discussions steering the protocol development in certain ways. By agreeing on some goals and reaching consensus about current state of the development, the community, dev and research teams work together to progress in this abstract roadmap. \n\n## The Infinite Garden\n\n> *Ethereum is NOT a zero sum game with a clear finish line, but rather a game that we want to play continuously. For that to be a reality, the Infinite Garden needs to upgrade regularly, on topics like its security, scalability or sustainability, until it reaches ossification. After that point there will probably be, just some trims - here and there.*\n\n## Core R&D\n\nThe discussion, resources and all research and development on the core protocol is fully open, free and public. Anyone can learn about it (as you are probably doing in this wiki) and further more, anyone can participate. There is no set of individuals which could push core protocol changes, the Ethereum community can raise the voice to help steer the discussion. To learn more about the core R&D shaping the protocol, read the [wiki page about it](/wiki/dev/core-development.md).\n\n## Roadmap overview \n\nWhile there is not a single roadmap that Ethereum development follows, we can track the current R&D efforts to map what changes are happening and might happen in the future. \nA popular overview mapping many domains of the current core research and development is Vitalik's chart (December 2023):\n\n![Ethereum roadmap updated by V.B. Dec2023](../research/img/full_roadmap2024_1600x1596.webp)\n\nIn this overview, different domains are coupled to related categories forming various 'urges'. Many of these boxes have their own page on this wiki where you can study more. \n\n### The Merge\n\nUpgrades relating to the switch from proof-of-work to proof-of-stake. The Merge was successfully achieved at Thu Sep 15 06:42:42 2022 UTC, reducing the network's annualized electricity consumption by more than 99.988%. However, this category also tracks subsequent upgrades which can be done to improve the consensus mechanism and smooth issues we encounter after The Merge. \n\n**IMPLEMENTED**\n| Upgrade | Description | Effect | State of the art |\n|:------------------------------------ |:---------------------------------------------------------------------------------------------------:|:-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:|:---------------------------------------------------- |\n| Launch the Beacon Chain | A crucial step in Ethereum's shift to a proof-of-stake consensus mechanism | Beacon Chain was launched as an independent network connected to Ethereum, bootstrapping validators in preparation for the Merge. | shipped
EIP-2982[^1] |\n| Merge Execution and Consensus Layers | Ethereum's execution layer merged with the Beacon chain (consensus layer) | Proof-of-work activities ceased and the network's consensus mechanism shifted to proof-of-stake. Validators have the role and responsibility for processing the validity of all transactions and proposing blocks | shipped |\n| Enable Withdrawals | The last of the three-part process of Ethereum's transition to a proof-of-stake consensus mechanism | Validators can add their withdrawal credentials and Beacon Chain sweeps all inactive ETH | shipped
EIP-4895[^2] |\n\n**TODO** \n| Upgrade | Description | Expected effect | State of the art |\n| :----------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------: | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :---------------------------------------------------------------------------------------------------------------- |\n| Single slot finality (SSF) | Blocks could be proposed and finalized in the same slot | (i) More convenient for apps (transactions finalization time improved by an order of magnitude, i.e. 12 seconds instead of 12 minutes means better UX for all. Under [full rollup scaling](#the-surge), with real-time SNARK proofs implemented, single slot finality would also mean faster bridging for L2s ), (ii) Much more difficult to attack (multi block MEV re-orgs can be eliminated and the complexity in consensus mechanism, reduced) | in research
(i) VB's SSF notes[^3]
(ii) 8192 signatures post-SSF[^4]
(iii) simple SSF protocol[^5] |\n| Single Secret Leader Election (SSLE) | Allow elected block proposers to remain private until block publishing, to prevent DoS attacks | Only the selected validator knows it has been selected to propose a block. | in research
EIP-7441[^6] |\n| Enable more Validators | The technical challenge of efficiently coordinating an ever increasing number of validators to achieve SSF with the best trade-offs possible | Greater redundancy, a broader range of proposers, a wider array of attesters, and overall increased resilience | in research
(i) EIP-7514[^7]
(ii) EIP-7251[^8]
(iii) 8192 signatures[^5] |\n| Quantum-safe signatures | Proactive research and integration of quantum-resistant cryptographic algorithms | Quantum-safe, aggregation-friendly signatures will enhance protocol security against quantum attacks | in research
(i) lattice-based[^9]
(ii) STARK-based [^10] systems |\n### The Surge\nUpgrades related to scalability by Roll-ups and Data Sharding. \n\n**IMPLEMENTED**\n| Upgrade | Track | Topic | Description | Effect | State of the art |\n| :----------------- | :---: | :------------------: | :----------------------------------------------------------------------------------------------------------------------------------------------------------------: | :-----------------------: | :------------------------- |\n| Proto-danksharding | - | Basic rollup scaling | We can stop storing Rollup data permanently on Ethereum and move the data into a temporary 'blob' storage that gets deleted from Ethereum once is no longer needed | Reduced transaction costs | shipped
EIP-4844[^11] |\n\n**TODO** \n| Upgrade | Track | Topic | Description | Expected effect | State of the art |\n| :---------------------------------------------- | :---: | :-------------------------: | :----------------------------------------------------------------------------------------------------------------------------------------: | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Danksharding | - | Full rollup scaling | Danksharding is the full realization of the rollup scaling that began with Proto-Danksharding | Massive amounts of space on Ethereum for rollups to dump their compressed transaction data | in research
|\n| Data Availability Sampling (DAS) | - | Full rollup scaling | Data Availability Sampling is a way for the network to check that data is available without putting too much strain on any individual node | (i) ensure rollup operators make their transaction data available after EIP-4844 (ii) ensure block producers are making all their data available to secure light clients (iii) under proposer-builder separation, only the block builder would be required to process an entire block, other validators would verify using data availability sampling | in research
EIP-7594[^12] |\n| Removing Rollup Training Wheels | - | Basic & Full rollup scaling | (i) Optimistic Rollup Fault Provers
(ii) ZK-EVMs
(iii) Rollup interoperability | (i) Optimistic rollups having live proof systems will address the L2's censorship risk
(ii) Massive improvements to Ethereum's scalability and privacy without sacrificing the security and decentralization aspects of the chain via zkEVMs (EVM-compatible virtual machines that supports zero-knowledge proof computation)
(iii) L1 Sequencers, or Ethereum L1 proposers with given rollup sequencing rights will bring better credible-neutrality and security, and offer roll-ups L1 compatibility | in research
(i)Arbitrum BoLD[^13]
Optimism Cannon[^14]
(ii) ZK-EVMs [^15] [^16] [^17]
(iii) [ET](/wiki/research/PBS/ET.md),
[Based Sequencing with Preconfirmations](/wiki/research/Preconfirmations/BasedSequencingPreconfs.md) |\n| Quantum-safe and Trusted-Setup-Free Commitments | - | - | replace KZG commitments with commitments that don't require a trusted setup and are quantum safe | Quantum-safe Commitments | in research
|\n\n### The Scourge\nUpgrades related to censorship resistance, decentralization and mitigating protocol risks from MEV and liquid staking/pooling. \n\n**IMPLEMENTED**\n| Upgrade | Track | Topic | Description | Effect | State of the art |\n| :-------- | :-------: | :-------------------------------: | :------------------------: | :-------------------------------------------------------------------------------------------------------------------------------------: | :----------------------------------------------- |\n| MEV-Boost | MEV-Track | Endgame Block Production Pipeline | Extra-protocol MEV markets | Ethereum community successfully commoditized MEV (partially), via an extra-protocol market. The majority of MEV goes now to Validators. | [shipped](/wiki/research/PBS/mev-boost.md)
|\n| Increase MAX_EFFECTIVE_BALANCE | Staking Economics | Raising Validator Cap | Increase the maximum effective balance for Ethereum validators from 32 ETH to 2048 ETH | Consolidates validators, reduces network load, and simplifies operations for large stakers | shipped
EIP-7251[^27] |\n\n**TODO** \n\n| Upgrade | Track | Topic | Description | Expected effect | State of the art |\n| :--------------------------------- | :-------: | :-------------------------------: | :------------------------------------------------------------------------------------------------------------------------------------------------------: | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :--------------------------------------------------------------------------------------------------------- |\n| ePBS | MEV-Track | Endgame Block Production Pipeline | Enshrinement of block Proposer and block Builder separation at protocol level, because of anti-censorship and MEV risk mitigation reasons | (i) creates opportunities to prevent transaction censorship at the protocol level
(ii) prevents hobbyist validators from being out-competed by institutional players that can better optimize the profitability of their block building
(iii) helps with scaling Ethereum by enabling the Danksharding upgrades | [in research](/wiki/research/PBS/ePBS.md)[^18]
|\n| MEV - Burn | MEV-Track | Endgame Block Production Pipeline | A simple enshrined PBS add-on to smooth and redistribute MEV spikes | The extracted ETH would be burned, therefore benefiting all ETH holders, rather than only those running validators. | [in research](/wiki/research/PBS/ePBS.md#mev-burn)[^19] |\n| ET | MEV-Track | Endgame Block Production Pipeline | A permissionless market allowing buyers to purchase the right to propose execution payloads. | Attester - Proposer separation: the beacon proposer is unconcerned with execution proposer. Execution proposer is selected from the permissionless execution tickets market and has the option to transfer the execution building right to a third party.
Since ET market will be a protocol gadget, the protocol will have introspection over who comes to market and how much they are willing to pay | [ET](/wiki/research/PBS/ET.md),
APS-Burn[^20] |\n| IL | MEV-Track | Endgame Block Production Pipeline | Inclusion lists - a way for the most decentralized set of Ethereum to fight censorship by inputting their preferences onto the construction of the chain | Prevents block builders from censoring blocks. Allow Proposers to retain some authority by providing a mechanism by which transactions can be forcibly included, avoiding the current situation, when without any forced transaction inclusion mechanism, the proposer is faced with the choice of either having to say no, on the transactions that get included, or they build the block locally (having the final say on transactions) and sacrifice some MEV rewards | [in research](/wiki/research/inclusion-lists.md)[^21]
Multiplicity gadgets [^22]
COMIS [^23] |\n| Distributed Block Building | MEV-Track | Endgame Block Production Pipeline | Decentralize the block building process, by distributing it | Decentralize different parts of the Builder:
(i) the algorithms for choosing transactions (the block building transaction ordering)
(ii) resources for block construction, especially under full Danksharding (split-up big blocks)
(iii) add extra builder services (e.g.Preconfirmations) | in research
[Preconfirmations](/wiki/research/Preconfirmations/Preconfirmations.md),
SUAVE[^24] |\n| Application Layer MEV Minimization | MEV-Track | - | App layer effort to minimize harmful MEV | The minimization techniques target:
(i) frontrunning, and
(ii) sandwich attacks | Examples[^25] |\n| Preconfirmations | MEV-Track | - | Users preconfirmations on transaction execution, for a competitive user experience in Ethereum interactions | Block builders could publicly agree to include transactions with a priority fee over a certain amount, and send users a receipt indicating their intent to include the transaction in a specific block | [in research](/wiki/research/Preconfirmations/Preconfirmations.md)[^26] |\n| Cheaper Nodes | Staking Economics | Improve Node Operator Usability| Make nodes cheaper and easier to operate using verkle trees and SNARKs | Lower SSD requirements, faster sync times, easier node operation | Research/Proposal: [in eps node workshop](/docs/eps/nodes_workshop.md)[^28] |\n| Capping Validator Set | Staking Economics | Explore Total Stake Capping | Cap the total amount of stake to manage communication overhead between validators | Prevents excessive validator participation, maintains network efficiency | Research/Proposals: [in research](/wiki/research/eODS.md)[^29] |\n|Combat LST Centralization | Staking Economics | Explore Solutions to Liquid Staking Centralization | Solutions to reduce centralization in the Liquid Staking Token (LST) market | Prevents large LST providers from gaining too much control over the network | Research/Proposals: [^30], [^31], [^32], [^33],[^34] |\n\n\n \n### The Verge\nUpgrades related to verifying blocks more easily\nSuccinct proofs for light-client security and state verification.\n\n| Upgrade | Track | Topic | Description | Expected effect | State of the art |\n|:--------------------------------:|:---------------:|:------------------------:|:------------------------------------------------------------------------:|:-----------------------------------------------------:|:--------------------------:|\n| Data Availability Sampling (DAS)| Full rollup | Blob data verification | Probabilistic blob sampling for light clients without full downloads. | Secures L2 DA & light clients with minimal overhead. | in research / EIP-7594 ([eips.ethereum.org](https://eips.ethereum.org/EIPS/eip-7594)) |\n| Verkle Tree Commitments | Statelessness | Verifiable trie proofs | Replace Merkle proofs with vector commitments for O(1)-sized proofs. | Dramatically smaller proofs; leaner light clients. | draft / EIP-7736 ([eips.ethereum.org](https://eips.ethereum.org/EIPS/eip-7736)) |\n\n### The Purge \n\nTargets protocol and data bloat by pruning historical and inactive state. \n\nVitalik’s “Possible Futures” Part 5: “The Purge” stresses history and state expiry to balance permanence with efficiency ([Possible futures of the Ethereum protocol, part 5: The Purge](https://vitalik.eth.limo/general/2024/10/26/futures5.html)). \n\n| Upgrade | Topic | Description | Expected effect | State of the art |\n|:---------------------------------|:-----------------------:|:---------------------------------------------------------------------------------------------------------------------------:|:-----------------------------------------------:|:--------------------------------------------------------------------:|\n| History Expiry (EIP-4444) | Prune old blocks | Clients prune execution-layer blocks and receipts older than ~1 year, bounding disk usage. | Lowers storage requirements for full nodes. | draft / EIP-4444[^2search0] |\n| State Expiry (EIP-7736) | Verkle-based expiry | Remove inactive Verkle leaves not accessed for a defined period; resurrect via proofs when needed. | Shrinks active state size to ~20–50 GB. | draft / EIP-7736[^3search0] |\n\n---\n\n### The Splurge \n\nEncompasses additional features that, while non-urgent, greatly improve usability, security, and long-term resilience. \n\n| Upgrade | Category | Description | Expected effect | State of the art |\n|:------------------------------------|:----------------------:|:-----------------------------------------------------------------------------------------------------------------------------:|:-------------------------------------------------:|:---------------------------------------------------------------------------------------:|\n| Account Abstraction (EIP-4337) | UX / Wallets | Introduces UserOperation mempool, bundlers, and paymasters for smart-contract wallet txs without consensus changes. | Enables social recovery, sponsored txs, batched ops. | shipped / EIP-4337[^5search0] |\n| Quantum-Safe Signatures | Future-proofing | Research into hash-based, lattice-based, and STARK-based multi-signature schemes to replace BLS/ECDSA for validator and user signatures. | Protects PoS and user accounts from quantum attacks. | research / hash-based PQS[^6search1], NIST PQC overview[^6search3] |\n| Formal Verification Tooling | Safety / Audits | Expand toolchain for proving correctness of protocol clients and smart contracts using Coq, SMT, TLA+, Dafny, Isabelle/HOL. | Higher assurance of protocol invariants and client safety. | evolving / [ethereum.org][^7search0], benchmarking tools[^7search1] |\n\n---\n\n## Resources\n\n[^1] : [EIP-2982: Serenity Phase 0](https://eips.ethereum.org/EIPS/eip-2982), [[archived]](https://web.archive.org/web/20230928204358/https://eips.ethereum.org/EIPS/eip-2982)\n\n[^2] : [EIP-4895: Beacon chain push withdrawals](https://eips.ethereum.org/EIPS/eip-4895), [[archived]](https://web.archive.org/web/20240415201815/https://eips.ethereum.org/EIPS/eip-4895)\n\n[^3] : [VB's SSF notes](https://notes.ethereum.org/@vbuterin/single_slot_finality), [[archived]](https://web.archive.org/web/20240330010706/https://notes.ethereum.org/@vbuterin/single_slot_finality)\n\n[^4] : [Sticking to 8192 signatures per slot post-SSF](https://ethresear.ch/t/sticking-to-8192-signatures-per-slot-post-ssf-how-and-why/17989). [[archived]](https://web.archive.org/web/20240105131126/https://ethresear.ch/t/sticking-to-8192-signatures-per-slot-post-ssf-how-and-why/17989)\n\n[^5] : [A simple Single Slot Finality protocol](https://ethresear.ch/t/a-simple-single-slot-finality-protocol/14920), [[archived]](https://web.archive.org/web/20231214080806/https://ethresear.ch/t/a-simple-single-slot-finality-protocol/14920)\n\n[^6] : [EIP-7441: Upgrade BPE to Whisk](https://eips.ethereum.org/EIPS/eip-7441), [[archived]](https://web.archive.org/web/20231001031437/https://eips.ethereum.org/EIPS/eip-7441)\n\n[^7] : [EIP-7514: Add Max Epoch Churn Limit](https://eips.ethereum.org/EIPS/eip-7514), [[archived]](https://web.archive.org/web/20240309191714/https://eips.ethereum.org/EIPS/eip-7514)\n\n[^8] : [EIP-7251:Increase the MAX_EFFECTIVE_BALANCE](https://eips.ethereum.org/EIPS/eip-7251), [[archived]](https://web.archive.org/web/20240324072459/https://eips.ethereum.org/EIPS/eip-7251)\n\n[^9] : [Medium post on lattice encryption](https://medium.com/asecuritysite-when-bob-met-alice/so-what-is-lattice-encryption-326ac66e3175), [[archived]](https://web.archive.org/web/20230623222155/https://medium.com/asecuritysite-when-bob-met-alice/so-what-is-lattice-encryption-326ac66e3175)\n\n[^10] : [VB's hackmd post on STARK signature aggregation](https://hackmd.io/@vbuterin/stark_aggregation), [[archived]](https://web.archive.org/web/20240313124147/https://hackmd.io/@vbuterin/stark_aggregation)\n\n[^11] : [EIP-4844: Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844), [[archived]](https://web.archive.org/web/20240326205709/https://eips.ethereum.org/EIPS/eip-4844)\n\n[^12] : [EIP-7594: PeerDAS](https://github.com/ethereum/EIPs/pull/8105) \n\n[^13] : [BoLd: dispute resolution protocol](https://github.com/OffchainLabs/bold/blob/e00b1c86124c3ca8c70a2cc50d9296e7a8e818ce/docs/research-specs/BOLDChallengeProtocol.pdf)\n\n[^14] : [Fault proofs bring permissionless validation to the OP Sepolia testnet](https://blog.oplabs.co/open-source-and-feature-complete-fault-proofs-bring-permissionless-validation-to-the-op-sepolia-testnet/)\n\n[^15] : [Parallel Zero-knowledge Virtual Machine](https://eprint.iacr.org/2024/387), [[archived]](https://web.archive.org/web/20240415180222/https://eprint.iacr.org/2024/387)\n\n[^16] : [What is zkEVM](https://www.alchemy.com/overviews/zkevm), [[archived]](https://web.archive.org/web/20240129204732/https://www.alchemy.com/overviews/zkevm)\n\n[^17] : [Types of ZK-EVMs](https://vitalik.eth.limo/general/2022/08/04/zkevm.html), [[archived]](https://web.archive.org/web/20240329112600/https://vitalik.eth.limo/general/2022/08/04/zkevm.html)\n\n[^18] : [Barnabe - More pictures about proposers and builders](https://mirror.xyz/barnabe.eth/QJ6W0mmyOwjec-2zuH6lZb0iEI2aYFB9gE-LHWIMzjQ), [[archived]](https://web.archive.org/web/20240424010902/https://mirror.xyz/barnabe.eth/QJ6W0mmyOwjec-2zuH6lZb0iEI2aYFB9gE-LHWIMzjQ)\n\n[^19] : [MEV burn—a simple design](https://ethresear.ch/t/mev-burn-a-simple-design/15590), [[archived]](https://ethresear.ch/t/mev-burn-a-simple-design/15590)\n\n[^20] : [APS-Burn](https://mirror.xyz/barnabe.eth/QJ6W0mmyOwjec-2zuH6lZb0iEI2aYFB9gE-LHWIMzjQ#heading-aps-burn)\n\n[^21] : [Inclusion lists](https://eips.ethereum.org/EIPS/eip-7547), [[archived]](https://web.archive.org/web/20240309191147/https://eips.ethereum.org/EIPS/eip-7547)\n\n[^22] : [ROP-9: Multiplicity gadgets](https://efdn.notion.site/ROP-9-Multiplicity-gadgets-for-censorship-resistance-7def9d354f8a4ed5a0722f4eb04ca73b)\n\n[^23] : [Committee-enforced inclusion sets (COMIS)](https://ethresear.ch/t/the-more-the-less-censored-introducing-committee-enforced-inclusion-sets-comis-on-ethereum/18835), [[archived]](https://web.archive.org/web/20240310000045/https://ethresear.ch/t/the-more-the-less-censored-introducing-committee-enforced-inclusion-sets-comis-on-ethereum/18835)\n\n[^24] : [SUAVE](https://writings.flashbots.net/the-future-of-mev-is-suave), [[archived]](https://writings.flashbots.net/the-future-of-mev-is-suave)\n\n[^25] : [Examples of app layer MEV minimization](https://herccc.substack.com/i/142947825/examples-of-the-defensive-side-of-mev)\n\n[^26] : [Based preconfirmations](https://ethresear.ch/t/based-preconfirmations/17353), [[archived]](https://ethresear.ch/t/based-preconfirmations/17353)\n\n[^27] : [EIP-7251: Increase the MAX_EFFECTIVE_BALANCE](https://eips.ethereum.org/EIPS/eip-7251)\n\n[^28] : [Spin Up Your Own Ethereum Node - Ethereum.org](https://ethereum.org/en/developers/docs/nodes-and-clients/run-a-node/)\n\n[^29] : [Paths to SSF](https://ethresear.ch/t/orbit-ssf-solo-staking-friendly-validator-set-management-for-ssf/19928)\n\n[^30] : [Enshrining Liquid Staking/Decentralized Liquid Staking](https://notes.ethereum.org/@vbuterin/H1_5auGQd)\n\n[^31] : [Enshrined LST from Arixon](https://ethresear.ch/t/enshrined-lst-allocating-stake-to-node-operators/11053)\n\n[^32] : [Unbundling staking: towards rainbow staking](https://ethresear.ch/t/unbundling-staking-towards-rainbow-staking/11054)\n\n[^33] : [Liquid Staking Maximalism design by Dankrad](https://ethresear.ch/t/liquid-staking-maximalism/11050)\n\n[^34] : [Two-tiered staking from Mike Neuder](https://ethresear.ch/t/two-tiered-staking/11049)\n\n[ethereum/EIPs github repository](https://github.com/ethereum/EIPs/tree/master#ethereum-improvement-proposals-eips)\n\n[Roadmap on Ethereum.org](https://ethereum.org/en/roadmap/)\n\n[ethroadmap.com](https://ethroadmap.com/)\n\n" }, { "path": "docs/wiki/research/scaling/core-changes/core-changes.md", "content": "# Changes to Ethereum Core to Achieve Scalability\n\nWith the [Rollup-Centric Roadmap](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698) published by Vitalik Buterin in 2020, Ethereum has embarked on a path toward achieving scalability. The ultimate goals of Ethereum scalability can be summarized as follows:\n\n- Transition the execution layer (dApps) entirely to Layer 2 (L2) rollups.\n- Optimize Ethereum, the Layer 1 (L1), to serve primarily as the settlement and data availability layer.\n\nFollowing the [Merge](https://github.com/ethereum/consensus-specs/tree/dev/specs/bellatrix), (see the [consensus spec](https://github.com/ethereum/consensus-specs), [annotated spec](https://github.com/ethereum/annotated-spec/blob/master/merge/beacon-chain.md), and [execution spec](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/paris.md)), the Ethereum chain has been divided into two distinct chains: the [consensus layer (CL)](https://github.com/ethereum/consensus-specs) and the [execution layer (EL)](https://github.com/ethereum/execution-specs). The consensus layer is responsible for the security, decentralization, and censorship-resistant properties of Ethereum, while the execution layer is responsible for executing transactions within each new block proposed by the consensus layer. These transactions update the global state of the chain, which is securely stored on the CL.\n\nWhile the EL can be used for direct L1 dApp transactions, the goal, as mentioned earlier, is for dApp transactions to move entirely to L2 rollups. The EL will primarily be used by rollups to update the L2 state or as a backup if for some reasons the L2 is [stopping working](https://docs.arbitrum.io/sequencer#unhappyuncommon-case-sequencer-isnt-doing-its-job).\n\nThe CL will be used by rollups for Data Availability (DA) and to store proofs of validity, especially for ZK rollups. To achieve scalability and reduce gas costs, storing data on the CL blocks must be affordable in the long term. To accomplish this ambitious roadmap, the development of the CL can be outlined in the following phases:\n\n- Proto-danksharding ([EIP-4844](https://eips.ethereum.org/EIPS/eip-4844)), the upgrade introducing blobs (live on March 14th, 2024).\n- Increasing [blob count & gas modifications](https://ethresear.ch/t/on-increasing-the-block-gas-limit/18567) (planned for EOY 2024).\n- Addition of [PeerDAS](https://ethresear.ch/t/peerdas-a-simpler-das-approach-using-battle-tested-p2p-components/16541).\n- Full implementation of [Danksharding](https://ethresear.ch/t/from-4844-to-danksharding-a-path-to-scaling-ethereum-da/18046).\n\nIn the following section, we discuss how EIP-4844 will impact the EL and CL.\n" }, { "path": "docs/wiki/research/scaling/core-changes/eip-4844.md", "content": "# EIP-4844\n\n## Overview\n\nL2 Rollups must allow the permissionless reconstruction of the L2 state. To achieve this, they must ensure Data Availability, which refers to the global ordering of inputs for transactions that have altered the state.\nBefore 4844 was live on mainnet, rollups have been storing data only via a section of the transaction known as `calldata`.\n\n[EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) introduces \"Blobs\", which modifies the current transaction and block structure defined in the [execution-specs](https://github.com/ethereum/execution-specs/blob/0f9e4345b60d36c23fffaa69f70cf9cdb975f4ba/src/ethereum/london/fork_types.py#L49) and [consensus-specs](https://github.com/ethereum/consensus-specs/blob/1a33bf8a00bb593d61a9128c929b8dcacef0b437/specs/deneb/beacon-chain.md#beaconblockbody) respectively.\n\nEIP-4844 introduces a new transaction type, the blob-carrying transaction.\n\nQuoted from [proto-danksharding-faq(aka EIP-4844)](https://notes.ethereum.org/@vbuterin/proto_danksharding_faq#What-is-proto-danksharding-aka-EIP-4844):\n\n> The main feature introduced by proto-danksharding is new transaction type, which we call a blob-carrying transaction. A blob-carrying transaction is like a regular transaction, except it also carries an extra piece of data called a blob. Blobs are extremely large (~125 kB), and can be much cheaper than similar amounts of calldata. However, blob data is not accessible to EVM execution; the EVM can only view a commitment to the blob.\n\nThis page outlines the EIP, providing code references to understand the changes brought by this hard fork. It targets aspiring Ethereum core developers interested in comprehending Ethereum's code post-update.\n\n## Core changes\n\n### New Gas Handling\n\n`calldata` has represented a primary bottleneck for scaling Ethereum, as storing data in `calldata` is costly, with plans to make it [even more so](https://eips.ethereum.org/EIPS/eip-7623).\n\n[EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) introduces \"Blobs\" a new way to store data within a transaction that will be significantly cheaper than using `calldata`. This is because Blobs will utilize a new type of gas, independent from the conventional gas, and follow their own pricing rules.\n\nEIP-4844 marks the initial step towards [achieving more efficient gas usage](https://ethresear.ch/t/on-increasing-the-block-gas-limit/18567).\n\nThe aim of these EIPs is to achieve a smaller and less variable block size. This goal is beneficial for two main reasons: it offers protection for solo stakers and creates additional capacity for future Blob storage.\n\nBut how can we achieve a smaller and less variable block size? One method is by increasing the cost of non-zero `calldata` bytes as proposed in [EIP-7623](https://eips.ethereum.org/EIPS/eip-7623). Raising the `calldata` cost reduces the maximum possible block size (assuming the `gas limit` remains at 30,000,000 and the gas cost for each `calldata` byte increases, resulting in fewer bytes fitting inside a block). Moreover, the increased `calldata` costs further encourage the use of Blobs for data availability.\n\nThe exploration of new, efficient ways to manage gas and the block gas limit remains [a subject of active discussion](https://ethresear.ch/t/on-increasing-the-block-gas-limit/18567).\n\n### Changes on the Consensus Specs\n\nThe upgrade which will introduce EIP-4844 into the Consensus Layer has been labeled **Deneb**.\n\n#### 1. Beacon Block Data Structure changes\n\nThe `BeaconBlockBody` (the data structure representing a block of transactions in the Consensus Layer) is updated to include 2 new more fields: `blob_kzg_commitments` and an updated version of the `execution_payload` field.\n\nSee [here](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/beacon-chain.md#beaconblockbody).\n\nIs important to note that Blobs will not be added to the block to which they belong to. They will instead referenced in the block by using the `blob_kzg_commitments`. Blobs are propagated separately to the network via \"sidecars\".\n\nKZG commitments are a type of cryptographic commitment particularly useful for their efficiency in creating and verifying proofs of data availability and correctness.\n\nKZG commitments provide the ability to prove that specific pieces of data are included in the set without revealing the entire dataset. This is particularly useful for scalability solutions because it does not require for every node to store the whole blockchain to prove transactions correctness.\n\nCheck the following links to learn more:\n\n- [KZG Ceremony](https://github.com/ethereum/kzg-ceremony)\n- [Arithmetic hash based alternatives to KZG for proto-danksharding (EIP-4844)](https://ethresear.ch/t/arithmetic-hash-based-alternatives-to-kzg-for-proto-danksharding-eip-4844/13863)\n- [Sharding multi-party computation ceremony](https://ethresear.ch/t/sharding-multi-party-computation-ceremony/11779)\n\n#### 2. Blob Sidecars\n\nAs stated in the [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844#consensus-layer-validation) blobs are referenced but not fully encoded inside the [beacon block body](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/beacon-chain.md#beaconblockbody). Instead of embedding the full contents in the body, the blobs are propagated separately, as \"sidecars\".\n\nFor the sidecar data structure, see [here](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/p2p-interface.md#blobsidecar)\n\nBefore propagating the blob sidecars to the p2p network, nodes must verify the Blobs are valid (see [here](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/p2p-interface.md#blob-subnets)).\n\nWhen a node requests a blob to the network the network responds with a `BlobSidecar` data structure.\nThe node receiving the sidecar should verify that blob sidecar is well-formatted, has valid inclusion proof, and is correct w.r.t. the expected KZG commitments before reading the data in a blob.\n\nThis \"sidecars\" design provides forward compatibility for further data increases by black-boxing [is_data_available](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/fork-choice.md#is_data_available), which means that in future upgrades `is_data_available()` implementation may change, for example to include data-availability-sampling (DAS), and the system interacting with this function is not required to understand the inner implementation of the function (in programming terms, `is_data_available()` can be considered as an interface method where the implementation may change over time).\n\n#### 3. Inclusion of KZG Commitment versioned hashes\n\nThe Consensus Layer (CL, also called Beacon chain) calls the [`process_execution_payload`](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/beacon-chain.md#modified-process_execution_payload) function when a new block payload is submitted to the chain. This function is responsible to perform some validity checks on the block's payload and then invoke the Execution Layer (EL) via the `verify_and_notify_new_payload` function.\n\nOnce invoked, the EL will:\n\n- validate the block payload\n- execute transactions inside the block payload\n- update the state, which is the result of executing transactions\n\nWith EIP-4844, the `process_execution_payload` adds the parameter `versioned_hashes` to be passed to the `verify_and_notify_new_payload` function.\n\n`versioned_hashes` is an array of [hashes](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/beacon-chain.md#modified-process_execution_payload) for each blob of KZG Commitment.\n\n#### 4. Execution Payload and Execution Payload Header\n\nThe Execution Payload [which is the payload sent from the Consensus Layer to the State Transition Function on the Execution Layer](https://github.com/ethereum/consensus-specs/blob/1a33bf8a00bb593d61a9128c929b8dcacef0b437/specs/deneb/beacon-chain.md#execution-payload) is extended with two new 64-bit unsigned integer fields, `blob_gas_used` and `excess_blob_gas`. Blob transactions have their own gas targeting rules (as described in the above section) and nodes must take into account gas spent to store data in blobs in addition to the normal gas fees spent to execute transaction (see below in **Changes on the Execution Specs**).\n\n- See [1](https://github.com/ethereum/consensus-specs/blob/1a33bf8a00bb593d61a9128c929b8dcacef0b437/specs/deneb/beacon-chain.md#executionpayload) and [2](https://github.com/ethereum/consensus-specs/blob/1a33bf8a00bb593d61a9128c929b8dcacef0b437/specs/deneb/beacon-chain.md?plain=1#L149)\n\n#### 5. New Block Header checks\n\nSee go-ethereum file \"consensus.go\" for checks added to the block header:\n\n- [link](https://github.com/ethereum/go-ethereum/blob/0a2f33946b95989e8ce36e72a88138adceab6a23/consensus/beacon/consensus.go#L274C1-L284C3)\n\n### Changes on the Execution Specs\n\nThe upgrade which will introduce EIP-4844 into the Execution Layer has been labeled **Cancun**.\n\n#### 1. Add checks inside the State Transition Function\n\nThe EL now must check that the blob specific fields are valid for each transaction that is going to be executed in the State Transition Function (STF).\n\nThe checks include (For the specs code, see [here](https://eips.ethereum.org/EIPS/eip-4844#execution-layer-validation)):\n\n- check that the signer has enough balance to cover the cost of both transaction gas fee and blob gas fees\n\n```python\n# modify the check for sufficient balance\nmax_total_fee = tx.gas * tx.max_fee_per_gas\nif get_tx_type(tx) == BLOB_TX_TYPE:\n max_total_fee += get_total_blob_gas(tx) * tx.max_fee_per_blob_gas\nassert signer(tx).balance >= max_total_fee\n```\n\n- check that the blob transaction contains at least 1 valid `blob_versioned_hash` (see CL changes) and that they are formatted correctly\n\n```python\nassert len(tx.blob_versioned_hashes) > 0\n```\n\n- check that the user is willing to pay at least the current blob base fee\n\n```python\nassert tx.max_fee_per_blob_gas >= get_blob_base_fee(block.header)\n```\n\nFinally, the EL STF must keep track of the gas being gas used for blob transactions (same as it already happens for EIP1559 transactions).\n\n```python\nblob_gas_used += get_total_blob_gas(tx)\n```\n\n#### 2. New Transaction Data Structure (BLOB_TX_TYPE)\n\nBefore EIP-4844, the Transaction data structure was the following ([ethereum execution-specs repository](https://github.com/ethereum/execution-specs/blob/0f9e4345b60d36c23fffaa69f70cf9cdb975f4ba/src/ethereum/london/fork_types.py#L49C1-L108C2)):\n\n```python\n@slotted_freezable\n@dataclass\nclass LegacyTransaction:\n nonce: U256\n gas_price: Uint\n gas: Uint\n to: Union[Bytes0, Address]\n value: U256\n data: Bytes\n v: U256\n r: U256\n s: U256\n\n@slotted_freezable\n@dataclass\nclass AccessListTransaction:\n chain_id: U64\n nonce: U256\n gas_price: Uint\n gas: Uint\n to: Union[Bytes0, Address]\n value: U256\n data: Bytes\n access_list: Tuple[Tuple[Address, Tuple[Bytes32, ...]], ...]\n y_parity: U256\n r: U256\n s: U256\n\n@slotted_freezable\n@dataclass\nclass FeeMarketTransaction:\n chain_id: U64\n nonce: U256\n max_priority_fee_per_gas: Uint\n max_fee_per_gas: Uint\n gas: Uint\n to: Union[Bytes0, Address]\n value: U256\n data: Bytes\n access_list: Tuple[Tuple[Address, Tuple[Bytes32, ...]], ...]\n y_parity: U256\n r: U256\n s: U256\n\nTransaction = Union[\n LegacyTransaction, AccessListTransaction, FeeMarketTransaction\n]\n```\n\nThe `calldata` is encoded inside the `data` field of the Transaction class. The `calldata` is accessible by the EVM, and the format to encode and decode it is specified in the [Contract ABI](https://docs.soliditylang.org/en/latest/abi-spec.html).\n\nEIP-4844 will introduce two more fields in the Transaction class, which are `max_fee_per_blob_gas` and `blob_versioned_hashes`.\nEIP-4844 introduced a new transaction type where `TransactionType == BLOB_TX_TYPE` and the `TransactionPayload` is the rlp encoding of the class below.\n\nWith the EIP-4844, the new Transaction data structure will be the following:\n\n```python\n@slotted_freezable\n@dataclass\nclass BlobTransaction: # the class name may change\n chain_id: U64\n nonce: U256\n max_priority_fee_per_gas: Uint\n max_fee_per_gas: Uint\n gas: Uint\n to: Union[Bytes0, Address]\n value: U256\n data: Bytes\n access_list: Tuple[Tuple[Address, Tuple[Bytes32, ...]], ...]\n max_fee_per_blob_gas: U256\n blob_versioned_hashes: VersionedHash\n y_parity: U256\n r: U256\n s: U256\n```\n\n### New Parameters\n\n- [BLOB_TX_TYPE](https://github.com/ethereum/consensus-specs/blob/1a33bf8a00bb593d61a9128c929b8dcacef0b437/tests/core/pyspec/eth2spec/test/helpers/sharding.py#L24)\n- [BYTES_PER_FIELD_ELEMENT](https://github.com/ethereum/consensus-specs/blob/1a33bf8a00bb593d61a9128c929b8dcacef0b437/pysetup/spec_builders/deneb.py#L70)\n- [FIELD_ELEMENTS_PER_BLOB](https://github.com/ethereum/consensus-specs/blob/1a33bf8a00bb593d61a9128c929b8dcacef0b437/pysetup/spec_builders/deneb.py#L71)\n- [BLS_MODULUS](https://github.com/ethereum/consensus-specs/blob/dev/specs/_features/whisk/beacon-chain.md#bls)\n- [VERSIONED_HASH_VERSION_KZG](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/beacon-chain.md#blob)\n- [MAX_BLOB_GAS_PER_BLOCK](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/beacon-chain.md#execution)\n- [GAS_PER_BLOB](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/beacon-chain.md#execution)\n- [MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS](https://github.com/ethereum/consensus-specs/blob/1a33bf8a00bb593d61a9128c929b8dcacef0b437/configs/mainnet.yaml#L148)\n\n### New Type Aliases\n\n- [Blob](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/polynomial-commitments.md#blob)\n- [VersionedHash](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/beacon-chain.md#custom-types)\n- [KZGCommitment](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/polynomial-commitments.md#custom-types)\n- [KZGProof](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/polynomial-commitments.md#custom-types)\n\n### New Cryptographic Helpers\n\n- [verify_kzg_proof()](https://github.com/ethereum/consensus-specs/blob/86fb82b221474cc89387fa6436806507b3849d88/specs/deneb/polynomial-commitments.md#verify_kzg_proof)\n- [verify_blob_kzg_proof_batch()](https://github.com/ethereum/consensus-specs/blob/86fb82b221474cc89387fa6436806507b3849d88/specs/deneb/polynomial-commitments.md#verify_blob_kzg_proof_batch)\n\n### New Opcodes\n\n- [BLOBHASH](https://github.com/ethereum/execution-specs/blob/0f9e4345b60d36c23fffaa69f70cf9cdb975f4ba/lists/evm/proposed-opcodes.md?plain=1#L60)\n\n## A note about previous attempts/research to improve scalability for rollups\n\nTo enhance scalability, two Ethereum Improvement Proposals (EIPs) were proposed: [EIP-4488](https://eips.ethereum.org/EIPS/eip-4488) and [EIP-4490](https://github.com/ethereum/EIPs/pull/4490).\n\nAt their core, both EIPs aim to reduce the gas cost associated with transaction `calldata`. EIP-4490 suggests lowering the `calldata` cost from 16 to 6 gas per byte. This change, while straightforward to implement, could potentially increase the maximum block size to 5MB. Conversely, EIP-4488 proposes a more significant reduction, from 16 to 3 gas per byte, but introduces a cap on the amount of `CALLDATA` permitted in each block to limit block size effectively.\n\nFor a more detailed discussion on these two proposals, consider checking [this tweet](https://twitter.com/TimBeiko/status/1464268807854190594) by Tim Beiko.\n\nPlease note that the aforementioned EIPs, [EIP-4488](https://eips.ethereum.org/EIPS/eip-4488) and [EIP-4490](https://github.com/ethereum/EIPs/pull/4490), are now deprecated in favor of the introduction of Blobs.\n\n## Further Reading\n\n- [https://www.eip4844.com/](https://www.eip4844.com/)\n- [https://domothy.com/blobspace/](https://domothy.com/blobspace/)\n- [EIP-4844 Explained](https://www.youtube.com/watch?v=HT9PHWloIiU)\n" }, { "path": "docs/wiki/research/scaling/data-availability.md", "content": "# Data Availability\n\nA core responsibility of any layer-1 blockchain is to guarantee _data availability_.\n\nData availability refers to the availability of block data, i.e. headers and bodies containing the transaction tree. During synchronization, nodes download each block from its peers to verify it and add to local database. If the received block contains any incorrect transactions or any block validity rules, the is rejected as invalid. A block validation during sync is necessary for the node to operate trustlessly and build the current state which requires both historical and latest data. \n\nEthereum solves the data availability problem by requiring full nodes to download each block (and reject it if part of the data is unavailable). Each node can just request a specific block over p2p network from its peers and verify it locally. \n\nThe data availability becomes a bottleneck for scalable systems like rollups which aim to process a lot of data. Optimistic rollups require transaction data to be available for their fraud-proof mechanism to identify and prove the incorrect state transition. And even validity-proof-based systems require data availability to ensure liveness (e.g., to prove asset ownership for a rollup’s escape hatch or forced transaction inclusion mechanism).\n\nThus, the data availability problem for rollups (and other off-chain scaling protocols) is proving to the base layer (L1) that data for recreating the L2 state is available without requiring L1 nodes to download blocks and store copies of the data.\n\n## The Ethereum Approach (pre-4844)\n\nRollups on Ethereum are operated by a _sequencer_: a full node that accepts transactions from users on a L2, processes those transactions (using the rollup's virtual machine), and produces L2 blocks that update the state of contracts and accounts on the rollup.\n\nTo enable Ethereum to monitor and enforce a rollup’s state transitions, a special “consensus” contract stores a state root—a cryptographic commitment to the rollup’s canonical state (similar to a block header on the L1 chain) that is generated after processing all transactions in a new batch.\n\nAt intervals, the sequencers arranges transactions in a new batch, and publishes the batch to the L1 by calling the L1 contract that stores rollup batches and passing the compressed data as _calldata_ to the batch submission function. Effectively storing L2 data on the L1 to ensure the availability. \n\nThis was a significant cost overhead for L2s for which _blobs_ were introduced as an alternative. Compression techniques, such as removing redundancy, using bitmaps, exploiting common function signatures, employing scientific notation for large numbers, and utilizing contract storage for repetitive data, enabled the reduction of calldata size, leading to substantial gas savings.\n\n## Data Availability Sampling\n\nThe purpose of sampling is to provide the node a probabilistic guarantee that data is available. Light nodes do require a connection to other (honest) nodes to make samples. This is also true for full nodes in all blockchains – they don’t conduct data availability sampling but they require a connection to at least one other node that will provide them with historical data over the p2p network.\n\nIn DAS, each node only ends up downloading a small portion of the data, but the sampling is done _client-side_, and within each blob rather than between blobs. Each node (including client nodes that are not participating in staking) checks every blob, but instead of downloading the whole blob, they privately select N random indices in the blob (eg. N = 20), and attempt to download the data at just those positions.\n\nThe goal of this task is to verify that at least half of the data in each blob is _available_.\n\n![data-availability-sampling](../img/scaling/das.png)\n\n### Erasure Coding\n\nErasure coding allows us to encode blobs in such a way that if at least half of the data in a blob is published, anyone in the network can reconstruct and re-publish the rest of the data; once that re-published data propagates, the clients that initially rejected the blob will converge to accept it.\n\nOn a high level, an erasure correcting code works like this: A vector of `k` information chunks gets encoded into a _longer_ vector of `n` coded chunks. The rate `R = k/n` of the code measures the redundancy introduced by the code. Subsequently, from certain subsets of the coded chunks we can decode the original information chunks.\n\nIf the code is [_maximum distance separable_](https://www.johndcook.com/blog/2020/03/07/mds-codes/) (MDS), then the original information chunks can be recovered from any subset of size of coded chunks, a useful efficiency and robustness guarantee. The concept works on the simple principle that if you know 2 points of a line, you can uniquely determine the entire line. In other words: Once you know the polynomial’s evaluation at `t` distinct locations, you can obtain its evaluation at any other location (by first recovering the polynomial, and then evaluating it).\n\nWe require blocks to commit to the Merkle root of this \"extended\" data, and have light clients probabilistically check that the majority of the extended data is available, on which one of the three things is true\n\n- The entire extended data is available, the erasure code is constructed correctly, and the block is valid.\n- The entire extended data is available, the erasure code is constructed correctly, but the block is invalid.\n- The entire extended data is available, but the erasure code is constructed incorrectly.\n\nIn case (1), the block is valid and the light client can accept it. In case (2), it is expected that some other node will quickly construct and relay a fraud proof. In case (3), it is also expected that some other node will quickly construct and relay a specialized kind of fraud proof that shows that the erasure code is constructed incorrectly. If a light client receives no fraud proofs for some time, it will take that as evidence that the block is in fact valid.\n\nAn interesting implementation to study can be found [here](https://github.com/ethereum/research/tree/master/erasure_code/ec65536).\n\nOther resources:\n\n- https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding#what-is-the-data-availability-problem\n- https://hackmd.io/@alexbeckett/a-brief-data-availability-and-retrievability-faq\n- https://arxiv.org/abs/1809.09044\n- https://ethereum.org/en/developers/docs/data-availability/\n" }, { "path": "docs/wiki/research/scaling/scaling.md", "content": "# Scaling\n\nIn computer systems, scalability refers to the ability of a system to perform well under increased or expanding workloads. The primary purpose of blockchain is to handle users' transactions and manage network's ledger state. An increase in workload may result from either a higher demand for transactions by existing users or an increase in the volume of users.\n\n> **Scalability of a blockchain system can be defined as its capacity to process increasing volumes operations, i.e. more transactions without raising demands on network node operators**.\n\n## Scalability Limits\n\nFor each block included in the chain, a general agreement on its validity must be reached among a certain percentage of validator nodes, the consensus mechanism is the methodology to achieve this agreement. The **block latency** is the time that takes to a valid block to be included in the chain.\nEthereum uses a proof-of-stake (PoS) based consensus protocol known as [Gasper](https://eips.ethereum.org/assets/eip-2982/arxiv-2003.03052-Combining-GHOST-and-Casper.pdf) with an ideal block latency fixed in the specification by the constant `SECONDS_PER_SLOT` (12 seconds), however real block latency could be slightly different since blocks could be missed by a specific validator and not to be included in a specific slot.\n\nAnother fundamental blockchain design parameter is the **block size** that is the limit on the amount of data that can be stored in a single block. Ethereum has a config parameter called `gas_limit` to cap the computational effort needed to process a block, which effectively also limits the size of a block. Each operation that takes place within Ethereum, requires a certain amount of \"gas\" to complete. The total amount of gas for all operations within a block can't exceed Ethereum's `gas_limit`. This approach ensures the network's processing capacity isn't overextended. [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) defines Ethereum gas pricing mechanism that allows to dynamically adjust the block size to deal with transient network congestions (without never exceed the limit of 30M gas units) and incentivize the network to target a gas amount defined by `gas_target` (15M). A gas limitation restricts the number of transactions (and their computational complexity) that can be included in an Ethereum block.\n\nThe block latency and block size directly determine the transactional throughput of the blockchain, which is measured by the **TPS** (transactions per second) metric. Block latency can be influenced by a variety of factors, such as the computational power of the network nodes, the complexity of the consensus mechanism, the network traffic congestion and the block size. Hence, a network made up of a few high-performance nodes tightly connected to each other and using large block sizes can result in an exceptional blockchain with high TPS and remarkably low block latency. However, such a network would likely be highly centralized and require users to make significant trust assumptions.\n\nAnother obstacle to decentralization is the size of the blockchain state. **The property of data being accessible when it is needed is known as data availability**. Availability of state data must be guaranteed, including availability of enough data to allow any new node in the network to reconstruct the latest version of the blockchain without any trust assumptions. Have to hold all the data to guarantee data availability can result in high storage requirements for nodes and a lengthy synchronization process for new ones, which can hinder decentralization. Handling a large amount of data is also problematic in terms of network congestion and will require demanding high connection bandwidth from node operators. Ethereum discourages the indiscriminate state growth by making operations that read or write state very expensive.\n\nNote the tight relationship between the design and tuning of a blockchain (consensus mechanics, node requirements, state structure and size… ) and its capabilities of decentralization. High hardware or network bandwidth requirements to run a node result in harsh and expensive conditions that make it difficult to do so, directly impacting the number of nodes a blockchain will have. **To ensure decentralization, it is essential to make running a node affordable and feasible for everyone and incentivize users to do it**.\n\nAs part of the game-theory mechanism, to maintain the network sustainability, users must pay a fee to include their transactions. In Ethereum the price of fees is determined by the base fee of the protocol, the amount of gas consumed by a specific transaction and a priority market, those who pay higher priority fees are prioritized. Due to limited TPS, including a transaction in a high decentralized blockchain like Ethereum has become a valuable service. An increase transaction demand for a limited and fixed TPS raises fees to the network usability threshold and requires sacrificing decentralization and/or security in order to scale.\n\n> **Recalling the definition of scalability, classical blockchain systems are not scalable for mass adoption without sacrificing certain levels of decentralization.**\n\nThis problem is widely known as the **Blockchain Trilemma**, which states that blockchain networks must sacrifice either security, decentralization, or scalability, and maximizing all three at once is difficult. The holy grail of blockchain technology is to create a secure and decentralized transactional network that can achieve a high TPS rate.\n\n![\"Blockchain trilemma - Bankless.com\"](../img/scaling/blockchain-trilemma.png \"Blockchain trilemma - Bankless.com\")\n\n## Blockchain Modularity\n\nModern blockchain designs propose a \"divide et impera\" approach dividing the system into different specific functional components to independently maximize each vertex of the trilemma. This approach encapsulates the complexity in each part of the system and reduces the systemic complexity through the definition of simpler interaction interfaces for system components.\nFunctional components of a blockchain:\n\n- Consensus: Agreement mechanics among nodes of block building and transaction ordering.\n- Execution: Transaction execution mechanics that define the state evolution.\n- Data availability: Data availability mechanics that ensures that the data is available to be queried when it is required.\n- Settlement: Mechanics that guarantee the finality and immutability of transactions.\n\nModular blockchain approach suggests dividing a blockchain system into different logical layers. This results in a design with reduced systemic complexity, and simpler components that can be more easily optimized and re-engineered to introduce new scaling solutions.\n\n## Scaling Ethereum\n\nThe primary objective of Ethereum's scalability efforts is to increase TPS metric without compromising decentralization or security.\n\nLayer 1 scaling refers to all techniques that increases the TPS of the underlying blockchain protocol itself. A naive solution to scaling would be to use blockchains with \"bigger blocks\" that can reach higher TPS numbers. However, the problem with this approach is that increasing the number of transactions to be verified in a given time period may lead to a scenario where only a limited number of node operators—those with powerful enough hardware—can participate in the network. This, in turn, can lead to increased centralization. For this reason, an increase in the capacity of each block must be accompanied by various modifications to the protocol that allow decentralization to be maintained. Examples of layer 1 scaling solutions include sharding, Proof-Of-Stake consensus mechanisms, and protocol upgrades aimed at optimizing block processing efficiency.\n\n![\"Layer 1 Scaling\"](../img/scaling/layer-1-scaling.png \"Layer 1 Scaling\")\n\n> **An increase of gas limits will effectively expand the amount of computation and data that Ethereum can hold but will also raise the demands on network node operators. Another design choice that will directly affect the block size is the gas pricing of operations. Cheaper operations will allow the inclusion of a greater number of and more complex transactions within the same gas limits boundary.**\n\nLayer 2 scaling is the set of solutions built on top of Layer 1 blockchain protocols that can achieve a higher TPS without requiring an increase in Layer 1 resource consumption, while still relying on its security model. These solutions typically process transactions off-chain or by using alternative consensus mechanisms that are faster and more scalable than the main blockchain. Examples of Layer 2 scaling solutions include, State Channels, Plasma Chains, or Rollups.\n\n![\"Layer 2 Scaling\"](../img/scaling/layer-2-scaling.png \"Layer 2 Scaling\")\n\nThe solution predominantly adopted by the Ethereum community to solve the scalability problem is a multi-rollup-centric approach. Here, Ethereum acts as fundamental secure layer of Settlement, and Data Availability, while the majority of Execution tasks are delegated to upper layers referred to as Rollups. Rollups bundle multiple Layer 2 transactions into a single Layer 1 transaction. These transactions are stored in Layer 1, but their execution is delegated to off-chain mechanisms. This allows for significant scalability improvements without sacrificing security. Ethereum's high level of programmability makes possible to create scalable solutions on top of the platform through Ethereum smart contracts. As previously mentioned, to maintain a high level of decentralization, Ethereum imposes limitations on the computational and storage resources that transactions included in the blocks can use, through gas limitations. Therefore, the data stored in Layer 1 is minimized, with only raw transactions being stored along with a hash commitment of the Layer 2 state resulting from the execution of those transactions.\n\n> **Rollups can be seen as a way to compress transaction execution, thereby reducing the computational burden on the Layer 1 blockchain. This provides the possibility to increase the TPS while still maintaining the security level of Layer 1 for the Layer 2 transactions, as their data and Layer 2 state transition commitments are stored in Layer 1.**\n\n## Ethereum Core Changes Towards a Rollup-Centric Roadmap\n\nSee the [Next Section](/wiki/research/scaling/core-changes/core-changes.md).\n\n## Ethereum Layer 2 scaling\n\nGiven the current rollup-centric roadmap, multiple Layer 2 networks have emerged. These can be categorized into two main groups based on their security model: optimistic rollups and zk-rollups.\n\nBoth solutions have their own advantages, drawbacks, and unique tech stacks. However, they share a few core components:\n - Onchain contracts: These control the various rollups and may include smart contracts that track user deposits, monitor state updates, and more.\n - Offchain virtual machines (VMs): Usually a modified EVM-compatible chain that executes transactions.\n\nEthereum acts as both a data availability (DA) layer and a settlement layer, meaning that Layer 2s inherit the security of Layer 1. Once a rollup transaction is committed to Ethereum’s base layer, it cannot be rolled back. \nHistorically, rollups posted their transaction data in the `calldata` section of Ethereum transactions, but this led to excessive growth in historical node storage. EIP-4844 (proto-danksharding) introduces a new mechanism that allows rollups to submit data in blobs — a separate, more efficient data space — along with a separate gas model for blob usage and minor changes to how consensus nodes process this data. You can learn more about blobs, danksharding, and EIP-4844 in the [following section](https://epf.wiki/#/wiki/research/scaling/core-changes/eip-4844).\n\n### Optimistic Rollups\n\nOptimistic rollups emerged as a way to improve transaction throughput while still relying on cryptoeconomic incentives to inherit Ethereum's security.\nTheir verification model is based on a technique called optimistic verification—every transaction submitted to Layer 1 is assumed to be valid by default.\nAn entity called an operator or aggregator submits a batch of L2 transactions to Layer 1 in a process called anchoring. After that, there is a challenge period, during which anyone can dispute the validity of a transaction batch by submitting a fraud proof.\nIf a challenge is successful, the challenger is rewarded, and the operator is penalized through a process called slashing. This mechanism incentivizes operators to only submit transactions that won't be challenged.\n\n### ZK Rollups\n\nZK rollups are scaling solutions that enhance Ethereum’s throughput with mathematical certainty using advanced cryptographic techniques.\nTransactions on the Layer 2 are bundled into batches, and a zero-knowledge proof is generated to verify their correctness. This proof is then submitted to Layer 1, where it is verified. Once verified, there is mathematical assurance that all transactions in the batch are valid.\nAlthough they're called ZK rollups due to their use of zero-knowledge proofs, the primary benefit is actually succinctness—the ability to produce a compact proof that is much smaller than the actual size of all the transactions.\nThere are two main types of zero-knowledge proof systems used in practice, zk-SNARKs(Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) and zk-STARKs(Zero-Knowledge Scalable Transparent Argument of Knowledge). \nzk-SNARKs currently have broader adoption in the ZK rollup landscape, but zk-STARKs are gaining momentum due to their scalability and lack of a trusted setup.\n\n## Resources:\n\n- [Ethereum Consensus Mechanism](https://ethereum.org/developers/docs/consensus-mechanisms), [archived](https://web.archive.org/web/20240214225609/https://ethereum.org/developers/docs/consensus-mechanisms)\n- [Ethereum Proof-of-Stake Consensus Specifications](https://github.com/ethereum/consensus-specs/tree/dev?tab=readme-ov-file#ethereum-proof-of-stake-consensus-specifications), [archived](https://web.archive.org/web/20240208050731/https://github.com/ethereum/consensus-specs/tree/dev)\n- [Ethereum Proof-of-Stake Consensus Specifications](https://ethereum.github.io/consensus-specs/), [archived](https://web.archive.org/web/20240217155014/https://ethereum.github.io/consensus-specs/)\n- [Vitalik The Limits to Blockchain Scalability](https://vitalik.eth.limo/general/2021/05/23/scaling.html), [archived](https://web.archive.org/web/20240205202358/https://vitalik.eth.limo/general/2021/05/23/scaling.html)\n- [Ethereum Scaling](https://ethereum.org/en/developers/docs/scaling), [archived](https://web.archive.org/web/20240209083702/https://ethereum.org/en/developers/docs/scaling)\n- [An Incomplete Guide to Rollups](https://vitalik.eth.limo/general/2021/01/05/rollup.html), [archived](https://web.archive.org/web/20240212014637/https://vitalik.eth.limo/general/2021/01/05/rollup.html)\n- [Gemini Cryptopedia The Blockchain Trilemma: Fast, Secure, and Scalable Networks](https://www.gemini.com/cryptopedia/blockchain-trilemma-decentralization-scalability-definition), [archived](https://web.archive.org/web/20240209073156/https://www.gemini.com/cryptopedia/blockchain-trilemma-decentralization-scalability-definition)\n- [Combining GHOST and Casper](https://eips.ethereum.org/assets/eip-2982/arxiv-2003.03052-Combining-GHOST-and-Casper.pdf), [archived](https://web.archive.org/web/20230907004049/https://eips.ethereum.org/assets/eip-2982/arxiv-2003.03052-Combining-GHOST-and-Casper.pdf)\n- [Ethereum Blocks](https://ethereum.org/developers/docs/blocks), [archived](https://web.archive.org/web/20240214052915/https://ethereum.org/developers/docs/blocks)\n- [On Block Sizes, Gas Limits and Scalability](https://ethresear.ch/t/on-block-sizes-gas-limits-and-scalability/18444), [archived](https://web.archive.org/web/20240220230246/https://ethresear.ch/t/on-block-sizes-gas-limits-and-scalability/18444)\n- [L2beat: an overview of all L2 rollups](https://l2beat.com/scaling/summary)\n" }, { "path": "docs/wiki/testing/consensus-spec-tests.md", "content": "# Consensus-spec tests\n\n> :warning: This article is a [stub](https://en.wikipedia.org/wiki/Wikipedia:Stub), help the wiki by [contributing](/contributing.md) and expanding it.\n\nThe [consensus-spec-tests](https://github.com/ethereum/consensus-spec-tests) repository contains a collection of test vectors generated from the Ethereum consensus specifications. \nThese tests are used to verify the correctness of consensus client implementations against the [Ethereum consensus-specs](https://github.com/ethereum/consensus-specs).\n\nClient developers use these tests to confirm that changes to the protocol are implemented consistently across all consensus clients. \n\n---\n\n> ### Practical notes\n>\n>The `consensus-spec-tests` repository is quite large and can take several gigabytes of disk space. \nWhen running multiple consensus clients that rely on the same test vectors, it is technically possible to save space by creating **symlinks** from each client’s expected test directory to a single shared copy of `consensus-spec-tests`.\n>\n>However, this approach comes with risks:\n>- Different clients may depend on **different versions** of the test suite. \n Using the wrong version can result in **false negatives** (tests failing even though the client implementation is correct).\n ![consensus-spec-tests-different-versions](./img/consensus-spec-tests-different-versions.png)\n> \n>- Manually switching (`git checkout`) to the required test version for a client and rerunning the tests can cause **issues with unpacking SSZ Snappy files** and lead to failing tests.\n ![consensus-spec-tests-incorrect-unpacking-SSZ](./img/consensus-spec-tests-incorrect-unpacking-SSZ.png)\n> See [issue](https://github.com/sntntn/grandine/issues/15) for a concrete example.\n>\n> Because of this, the **recommended practice** is to **keep separate copies** of `consensus-spec-tests` for each consensus client, even if it requires more disk space.\n\n\n\n\nResources: \n- [consensus-spec-tests repo](https://github.com/ethereum/consensus-spec-tests) \n- [Ethereum consensus-specs](https://github.com/ethereum/consensus-specs) (source of truth for test generation) \n- [SimpleSerialize (SSZ) specification](https://ethereum.github.io/consensus-specs/ssz/simple-serialize/) \n\n" }, { "path": "docs/wiki/testing/formal-verification.md", "content": "# A brief introduction to formal verification\n\n## Overview\n\nFormal methods are techniques used for mathematical analysis of software and hardware systems. The philosophical roots of formal methods reach back to ancient Greece with Plato's exploration of theory of forms in his book \"Sophist\"; throughout 17th the century, mathematicians further developed the concept through abstract algebra. German polymath, Gottfried Leibniz's vision laid the groundwork for what we now call formal reasoning. In the 19th century, pioneering work by [George Boole](https://en.wikipedia.org/wiki/George_Boole) on analysis and [Gottlob Frege](https://en.wikipedia.org/wiki/Gottlob_Frege) on propositional logic provided the foundation for formal methods.\n\nUnder formal methods, formal verification is a _verification technique_ that helps find the answer to a simple question: \"Does a system correctly meet its required specifications?\". It does that by [abstracting a system](https://in.mathworks.com/discovery/abstract-interpretation.html) as a mathematical model and proving or disproving its correctness.\n\nA \"system\" is defined as a mechanism that is able to execute all of the functions given by its external interface. For a system, an \"invariant\" is a property that remains unchanged, regardless of its current state. For example, an invariant of a vending machine is: Nobody should be able to dispense a product for free. Formal verification tests the correctness of a system by checking if all its invariants holds true.\n\nThis rigorous method for scrutiny of systems scores the highest ranking on the [EAL scale](https://en.wikipedia.org/wiki/Evaluation_Assurance_Level#EAL7:_Formally_Verified_Design_and_Tested), signifying its profound impact on security.\n\nTypes of formal verification:\n\n- **Model checking / assertion-based checking**: Models a system as a finite state machine and verifies its correctness and liveness using propositional logic.\n- **Temporal logic**: Models a system whose propositions varies with time.\n- **Equivalence checking**: Verifies if two models of the same specification but varying implementations produce the same result.\n\n## Popular tools\n\n### Coq\n\n[Coq](https://coq.inria.fr/) is a widely adopted, open source proof management system. It was used to specify and formally verify the CompCert compiler for the C programming language. The compiler is used to [develop safety-critical programs](https://www.inria.fr/en/compcert-software-program-receives-prestigious-award) for aircraft, cars, and nuclear power plants.\n\n### TLA+\n\n[TLA+](https://lamport.azurewebsites.net/tla/tla.html) is a formal specification language developed by the Turing award-winner Leslie Lamport. It is mostly used for modeling concurrent and distributed systems. Amazon web services [uses TLA+](https://www.amazon.science/publications/how-amazon-web-services-uses-formal-methods) for verifying robustness of their distributed systems.\n\n### Alloy\n\n[Alloy](https://alloytools.org/) is an open source language and analyzer for software modeling. Notably, the flash file system design was [analyzed against the POSIX standard](https://eskang.github.io/assets/papers/ijsi09_kang_jackson.pdf) using Alloy.\n\n### Z3\n\n[Z3](https://www.microsoft.com/en-us/research/project/z3-3/) is a symbolic logic solver developed by Microsoft research. It is used in a wide range of software engineering applications, ranging from [program verification](https://www.aon.com/cyber-solutions/aon_cyber_labs/exploring-soliditys-model-checker/), compiler validation, testing, fuzzing, and optimization.\n\n## Example\n\nFormal verification of a system begins by selectively abstracting the system to create a focused model for correctness testing.\n\n[Dijkstra](https://en.wikipedia.org/wiki/Edsger_W._Dijkstra) elegantly describes this process:\n\n> I have grown to regard a program as an ordered set of pearls, a “necklace”. The top pearl describes the program in its\n> most abstract form, in all lower pearls one or more concepts used above are explained (refined) in terms of concepts\n> to be explained (refined) in pearls below it, while the bottom pearl eventually explains what still has to be explained\n> in terms of a standard interface (=machine). The family becomes a given collection of pearls that can be strung\n> into a fitting necklace.\n\nThe TLA+ spec to models a traffic controller:\n\n```bash\n-------------- MODULE TrafficController --------------\n\nCONSTANTS MaxCars\nVARIABLES carsWaiting, greenSignal\n\nInit == /\\ carsWaiting = 0\n /\\ greenSignal = FALSE\n\nArrive(car) == IF carsWaiting < MaxCars THEN carsWaiting' = carsWaiting + 1 ELSE UNCHANGED carsWaiting\n\nDepart == IF carsWaiting > 0 THEN carsWaiting' = carsWaiting - 1 ELSE UNCHANGED carsWaiting\n\nChangeSignal == /\\ carsWaiting > 0\n /\\ greenSignal' = TRUE\n\nNext == \\/\n \\E car \\in {0, 1}: Arrive(car)\n \\/ Depart\n \\/ ChangeSignal\n\nInvariant == carsWaiting <= MaxCars\n\nSpec == Init /\\ [][Next]_<> /\\ []Invariant\n\n=======================================================\n\n```\n\nUnderstanding the TLA+ semantics are not important for this discussion. Here is a brief of what it does:\n\n`Init` initializes the system with no cars waiting. The `Arrive` models the arrival of cars, increasing the count of waiting cars if the maximum capacity has not been reached. Conversely, the `Depart` simulates cars departing from the controller, decrementing the count of waiting cars if there are any. Lastly ,`ChangeSignal` dictates that if cars are waiting, the traffic signal switches to green.\n\nThe invariant `Invariant == carsWaiting <= MaxCars` ensures the number of cars waiting never exceeds `MaxCars`, a defined constant.\n\nNote how this abstraction conveniently ignores all the irrelevant interactions at a traffic signal (honking, anyone?).\n\n**Efficient abstraction is an art.**\n\n## Ethereum and formal verification\n\nSafety and liveliness assurance is central to Ethereum's decentralized infrastructure. Formal verification plays a critical role in verifying correctness of:\n\n- The protocol's [execution](/wiki/EL/el-specs.md) and [consensus](/wiki/CL/cl-specs.md) specifications.\n- [Client](/wiki/EL/el-clients.md) implementations.\n- On-chain smart contract applications end users interact with.\n\n### Protocol verification\n\nFormal verification is used by the [Runtime Verification team](https://github.com/runtimeverification) to verify [bacon chain specification](https://runtimeverification.com/blog/a-formal-model-in-k-of-the-beacon-chain-ethereum-2-0s-primary-proof-of-stake-blockchain), and the [Gasper finality mechanism](https://runtimeverification.com/blog/formally-verifying-finality-in-gasper-the-core-of-the-beacon-chain).\n\n[KEVM](https://github.com/runtimeverification/evm-semantics) builds upon [K framework](https://kframework.org/) for crafting formal semantics and conducting verification of the [Ethereum Virtual Machine (EVM)](/wiki/EL/evm.md) specification for correctness.\n\nFormal verification is an essential tool in the test suite and was used to discover a subtle [array-out-of-bound runtime error](https://consensys.io/blog/formal-verification-of-ethereum-2-0-part-1-fixing-the-array-out-of-bound-runtime-error) within the state transition component.\n\n![Formal verification as part of testing suite](./img/fv-and-testing.jpg)\n> Formal verification a slice of a Swiss cheese model in a test suite – [Source: Codasip](https://codasip.com/2023/09/19/formal-verification-best-practices-to-reach-your-targets/).\n\n### Verifying optimizations\n\nEquivalence checking is extensively used for software optimization. For example, an optimized smart contract can be tested for correctness against its previous version to confirm that the optimization hasn't introduced any unintended behavior.\n\n### Smart contract verification\n\nBugs or vulnerabilities in smart contracts can have devastating consequences, leading to financial losses and undermining user trust. Formal verification tools like tools [Certora Prover](https://docs.certora.com/en/latest/docs/prover/index.html) and [halmos](https://github.com/a16z/halmos) helps identify these issues.\n\nFor example, Runtime Verification formally verified a [deposit smart contract application](https://runtimeverification.com/blog/formal-verification-of-ethereum-2-0-deposit-contract-part-1) and found a [subtle bug](https://github.com/ethereum/deposit_contract/issues/26).\n\nFormal verification has always been an integral part of the [Solidity](https://soliditylang.org/) language. Here Christian from the Solidity team from an early workshop:\n\n\n\n---\n\nSolidity compiler also implements a [formal verification approach based on SMT (Satisfiability Modulo Theories) and Horn solving](https://docs.soliditylang.org/en/latest/smtchecker.html).\n\nLeo from EF Formal Verification team explains how to use this feature:\n\n\n\n---\n\n## Challenges with formal verification\n\nFormal verification is hard. The process itself can be [complex and time-consuming,](https://www.hillelwayne.com/post/why-dont-people-use-formal-methods) requiring specialized skills and tools. Additionally, formal verification can only guarantee the correctness of the model, not necessarily the underlying implementation itself. Errors in the translation process between model and code can still introduce vulnerabilities.\n\nFormal verification relies on efficient abstraction of a system. And abstraction is hard. If you leave an important detail out of the abstraction it can introduce safety issues. For this reason, often times [engineers use a complementary simulation method like fuzzing](https://blog.trailofbits.com/2024/03/22/why-fuzzing-over-formal-verification/) to test a system using random input.\n\nDespite these challenges, formal verification is a powerful technique that can help design safe and efficient systems. We'll close on this insightful quote from Dijkstra:\n\n> “Program testing can be used to show the presence of bugs, but never to show their absence!”\n\n## Resources\n\n### 🗣️ Talks\n\n- Grigore R., [Formal Verification of Smart Contracts and Protocols: What, Why, How](https://www.youtube.com/watch?v=xggtkB7w3es)\n- Roberto S.,[Formal Specification and Verification of the Distributed Validator Technology protocol](https://www.youtube.com/watch?v=xdEo5Tc6TiY)\n- Grant P., [Towards Imandra Contracts: Formal verification for Ethereum](https://www.youtube.com/watch?v=xeg_Q5uN73Q)\n- Rikard H., [Formal Methods for the Working DeFi Dev](https://www.youtube.com/watch?v=ETlNhV9jYJw)\n- Dimitar D. et al., [Formal Verification of Smart Contracts Made Easy](https://www.youtube.com/watch?v=tq5XH3JedqM)\n- Yoichi H., [Formal Verification of Smart Contracts](https://www.youtube.com/watch?v=cCUGMAnCh7o)\n- Yan M., [Ethereum Bugs Through the Lens of Formal Verification](https://www.youtube.com/watch?v=Ru6X043Q63U)\n- Pawel S., [Formal verification applied (with TLA+)](https://www.youtube.com/watch?v=l9XZYI3jta0)\n\n### 📄 Publications\n\n- NASA, [What is formal methods](https://shemesh.larc.nasa.gov/fm/fm-what.html)\n- Andrew H., [Formal Verification, Casually Explained](https://ahelwer.ca/post/2018-02-12-formal-verification/)\n- Bernie C., [A Brief History of Formal Methods](https://www.researchgate.net/publication/233960390_A_Brief_History_of_Formal_Methods)\n- Martin D., [Martin Davis on Computability, Computational Logic, and Mathematical Foundations](https://link.springer.com/book/10.1007/978-3-319-41842-1)\n- Ashish D., [A Brief History of Formal Verification](http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1969.PDF)\n- Serokell, [Formal Verification: History and Methods](https://serokell.io/blog/formal-verification-history)\n- Amazon, [How Amazon Web Services Uses Formal Methods](https://cacm.acm.org/research/how-amazon-web-services-uses-formal-methods/)\n- Codasip, [Formal verification best practices to reach your targets](https://codasip.com/2023/09/19/formal-verification-best-practices-to-reach-your-targets/)\n- Siemens, [How Can You Say That Formal Verification Is Exhaustive?](https://blogs.sw.siemens.com/verificationhorizons/2021/09/16/how-can-you-say-that-formal-verification-is-exhaustive/)\n- Siemens, [3 Notable Formal Verification Conference Papers of 2020](https://blogs.sw.siemens.com/verificationhorizons/2021/02/09/3-notable-formal-verification-conference-papers-of-2020/)\n- Siemens, [Formal Verification Methods](https://verificationacademy.com/topics/formal-verification/)\n- Stanford, [Introduction to First Order Logic](https://plato.stanford.edu/entries/logic-classical/)\n- NYU, [Introduction to Satisfiability Modulo Theories](https://cs.nyu.edu/~barrett/pubs/BT14.pdf)\n- Sebastian U, [A Formal Verification of Rust's Binary Search Implementation](https://kha.github.io/2016/07/22/formally-verifying-rusts-binary-search.html)\n- Jack V., [Primer on TLA+](https://jack-vanlightly.com/blog/2023/10/10/a-primer-on-formal-verification-and-tla)\n- Martin L., [Symbolic execution for hevm](https://fv.ethereum.org/2020/07/28/symbolic-hevm-release)\n- The Royal Society, [Formal verification: will the seedling ever flower?](https://royalsocietypublishing.org/doi/10.1098/rsta.2015.0402)\n" }, { "path": "docs/wiki/testing/hive.md", "content": "# Hive testing\n\n> :warning: This article is a [stub](https://en.wikipedia.org/wiki/Wikipedia:Stub), help the wiki by [contributing](/contributing.md) and expanding it.\n\n[Hive](https://github.com/ethereum/hive) is an end-to-end testing harness enabling simulators to [spin up various clients](https://github.com/ethereum/hive/blob/master/docs/clients.md) in a single network with different testing scenarios (simulations). It is a much easier way to test all clients at the same time under the same parameters to make sure none are failing. The tests also have very specific edge cases that can be modified for any possible edge case and simulation/scenario. Due to this simplicity, Hive plays a critical role in testing upcoming forks and network upgrades. \n\nIf you are curious and want to run some of your own tests and simulations, [install Hive](https://github.com/ethereum/hive/blob/master/docs/commandline.md)!\n\nHere are a list of [Hive Simulators](https://github.com/ethereum/hive/tree/master/simulators)\n\n[The Hive Simulator Programming guide](https://github.com/ethereum/hive/blob/master/docs/simulators.md) also explains how to write Hive simulators. \n" }, { "path": "docs/wiki/testing/incidents.md", "content": "# Notable mainnet incidents\n\n> :warning: This article is a [stub](https://en.wikipedia.org/wiki/Wikipedia:Stub), help the wiki by [contributing](/contributing.md) and expanding it.\n> Incidents are the disruptions, vulnerabilities and attacks faced by the network which has questioned it's stability and security. Below are some incidents that affected the network and their sources.\n\n## Overview\n\nThe Ethereum network has faced various challenges and incidents throughout its history. These incidents have helped improve the network's resilience and security through careful analysis and implementation of preventive measures. This page documents notable incidents that have affected the Ethereum.\n\nFor a comprehensive list of Ethereum incidents and their detailed analysis, you can refer to the [EthStaker Incidents Page](https://ethstaker.org/incidents).\n\n## Recent Incidents\n\n- [Post-Mortem, Holesky Finality Issue (24/02/2025)](https://github.com/ethereum/pm/blob/master/Pectra/holesky-postmortem.md)\n In February 2025, after Pectra upgrade on Holesky testnet, blocks were not getting finalized due to many EL clients having incorrect deposit contract address configurations. This caused some EL clients to reject the invalid blocks while others accepted them, resulting in network split.\n\n- [Post-Mortem, Blob Propagation Issues (27/03/2024)](https://gist.github.com/benhenryhunter/687299bcfe064674537dc9348d771e83)\n In March 2024, after Dencun upgrade, blobs attached to blocks from certain builders propagated too slowly over p2p which caused a client implementation to miss few slots.\n\n- [Post-Mortem Report: Ethereum Mainnet DOS Incident (07/02/2024)](https://blog.ethereum.org/2024/03/21/sepolia-incident)\n It was discovered that there was a possibility for a Denial-of-service attack dating from when the merge happened to the dencun hard fork. An attacker could create a block exceeding the specified limit of 5mb and adding multiple transactions into the block each not up to 128kb while also making sure that the transactions within the block have a collective gas which is below 30 million. With this action most nodes will reject the blocks which will lead to minority nodes acceptance creating forked blocks and missed proposer rewards.\n\n- [Post-Mortem Report: Ethereum Mainnet Finality (05/11/2023)](https://medium.com/offchainlabs/post-mortem-report-ethereum-mainnet-finality-05-11-2023-95e271dfd8b2)\n The Mainnet had some disruptions, which led to blocks not getting produced leading to a significant delay in transactions reaching finality, this continued for two days and resulted in an inactivity consequence, the network fully recovered without intervention.\n\n- [Reth Mainnet State Root Mismatch (01/09/2025](https://laced-king-de5.notion.site/Incident-Post-Mortem-Reth-Mainnet-State-Root-Mismatch-26732f2c348480dea8b8c2a8753696dc)\n A bug in Reth’s handling of trie updates caused trie tables in Reth nodes to contain incorrect information, resulting in nodes computing an incorrect state root at later blocks. \n\n## Historical Incidents\n\n- [Post-Mortem Report: Minority Split (2021-08-27)](https://github.com/ethereum/go-ethereum/blob/master/docs/postmortems/2021-08-22-split-postmortem.md)\n This happened when Geth tried to assign data back into memory after the `datacopy` operation. Instead of saving the data in a new location, it accidentally overwrote the original data, causing it to become corrupted.\n\n- [The DAO Attack (2016)](https://www.coindesk.com/learn/understanding-the-dao-attack)\n One of the most significant incidents in Ethereum's history, where a vulnerability in The DAO smart contract was exploited, leading to the loss of approximately 3.6M ETH. This incident ultimately led to a hard fork of the Ethereum blockchain, creating Ethereum Classic (ETC) and the current Ethereum (ETH) chain.\n\n- [Shanghai DOS Attacks (2016)](https://ethos.dev/shanghai-attacks)\n The network faced a series of DOS attacks during DevCon2 in Shanghai, where attackers exploited underpriced EVM opcodes (particularly EXTCODESIZE) to slow down block processing resulting in network congestion. This led to subsequent hard forks (Tangerine Whistle and Spurious Dragon) that adjusted gas costs for targeted opcodes to prevent similar attacks.\n\n" }, { "path": "docs/wiki/testing/kurtosis.md", "content": "# Kurtosis for Local Devnets\n\n## Overview \n[**Kurtosis**](https://docs.kurtosis.com/) is a development and testing platform designed to package and launch environments of containerized services efficiently. Kurtosis serves as a build system for multi-container test environments, helping developers set up Ethereum network instances that can be easily reproduced locally. The [**Ethereum package**](https://github.com/ethpandaops/ethereum-package), built on top of Kurtosis, enables the rapid setup of a customizable, scalable, and private Ethereum testnet using Docker or Kubernetes. It supports all major Execution Layer (EL) and Consensus Layer (CL) clients, efficiently managing local port mappings and service connections for validation and testing of Ethereum core infrastructure.\n\nThis article provides a brief introduction to Kurtosis, how to install and use it, and some essential commands for working with Ethereum devnets.\n\n## Installing Kurtosis\n\nBefore installing Kurtosis, ensure the following dependencies are pre-installed on your system:\n\n- Docker (required to run Kurtosis containers)\n- Git (to clone repositories)\n\nYou can install Kurtosis by following the official installation guide [here](https://docs.kurtosis.com/install).\n\nOnce installed, verify your setup by running:\n\n```sh\nkurtosis version\n```\n\nFor upgrade instructions, refer to the [Kurtosis upgrade guide](https://docs.kurtosis.com/upgrade).\n\n## Kurtosis Engine\n\nThe Kurtosis engine is the core service that runs the devnet infrastructure. It starts automatically as soon as you launch the devnet. However, here are some useful commands for interacting with the engine:\n\n```sh\n# Start the engine\nkurtosis engine start\n\n# Stop the engine\nkurtosis engine stop\n\n# Check the status of the engine\nkurtosis engine status\n```\n\n## Quick Start: Ethereum Package\n\nYou can quickly set up a default Ethereum devnet using the Ethereum package by following the instructions from the [ethereum-package GitHub page](https://github.com/kurtosis-tech/ethereum-package).\n\nThe shortest way to launch the devnet after installation is to run the package with default configurations:\n\n```sh\nkurtosis run github.com/ethpandaops/ethereum-package\n```\n\nThe running enclave status will appear:\n\n![Kurtosis quick start terminal](./img/kurtosis-quick-start.png)\n\nRun this command to open Kurtosis web interface:\n\n```sh\nkurtosis web\n```\n\n![Kurtosis web interface](./img/kurtosis-web.png)\n\n## Kurtosis Enclave\n\nAn **enclave** in Kurtosis is an isolated environment where services are deployed. It allows developers to create multiple devnets without interference. Key commands include:\n\n```sh\n# List existing enclaves\nkurtosis enclave ls\n\n# Inspect an enclave\nkurtosis enclave inspect \n\n# Example\nkurtosis enclave inspect my-testnet\n\n# Delete an enclave\nkurtosis enclave rm -f\n\n```\n\nExplore the enclave in the web interface by clicking on the enclave's name:\n\n![Kurtosis enclave in web interface](./kurtosis-web-enclave.png)\n\nYou can run multiple enclaves at the same time, but be cautious of your machine's resources to avoid performance issues. Additionally, assigning a custom name to each enclave can be useful when managing several enclaves simultaneously.\n\n```sh\n# assigning your name to enclave\nkurtosis --enclave my-testnet run github.com/ethpandaops/ethereum-package\n```\n\n## Cleaning Up Resources\n\nAfter testing, you may want to relaunch the devnets with new parameters or clean up resources to free disk space. Use the following command to remove stopped enclaves, as well as stopped engine containers:\n\n```sh\nkurtosis clean -a\n```\n\n> [!CAUTION]\n> All the enclaves will be deleted.\n\n## Customizing Devnets\n\nDevnets in Kurtosis are configured using YAML files stored locally or in the network. These files allow customization of parameters such as participants, network parameters, additional services. If a parameter is not specified in the file, the default value is used. An exhaustive list of all possible configuration parameters can be found [here](https://github.com/ethpandaops/ethereum-package?tab=readme-ov-file#configuration).  A common practice is to build client Docker images locally and add them to the configuration file using the `cl_image` or `el_image` parameters for testing purposes. \n\nExample file:\n\n```yaml\nparticipants:\n - el_type: geth \n el_image: geth:latest \n cl_type: teku\n cl_image: consensys/teku:develop\nadditional_services\n - dora\n - prometheus_grafana\nnetwork_params:\n seconds_per_slot: 4\nglobal_log_level: debug\n\n```\n\nTo run Kurtosis with these parameters, use the `--args-file` flag. For remote files, provide the raw URL of the desired file:\n\n```sh\n# local file\nkurtosis run github.com/ethpandaops/ethereum-package --args-file ./custom.yaml\n\n# remote file\nkurtosis run github.com/ethpandaops/ethereum-package --args-file https://raw.githubusercontent.com/ethpandaops/ethereum-package/main/.github/tests/mix.yaml\n```\n\nYou can find a detailed description of all parameters [here](https://github.com/ethpandaops/ethereum-package?tab=readme-ov-file#configuration).\n\n## Customizing Ethereum Package\n\nYou can clone the Ethereum package repository and develop on top of it. To run your own modifications, use the following command:\n\n```sh\nkurtosis run .\n\n# Example\nkurtosis run . --args-file ./custom.yaml\n```\n\n## Tooling\n\nKurtosis provides several built-in tools to interact with Ethereum devnets. Here are some examples:\n\n- [**dora**](https://github.com/ethpandaops/dora): A lightweight Beacon Chain explorer.\n\n- [**xatu**](https://github.com/ethpandaops/xatu): A centralized Ethereum network monitoring tool for data pipelining.\n\n- [**assertoor**](https://github.com/ethpandaops/assertoor): Used for writing assertions to verify network behavior.\n\nExample YAML file:\n\n```sh\n- el_type: nethermind\n cl_type: prysm\nadditional_services:\n - dora\n - assertoor\n```\n\nThe full list of services can be found [here](https\\://ethpandaops.io/posts/kurtosis-deep-dive/#tooling).\n\nSome of these tools have a web interface. To open the interface, use the link provided in the user services list:\n\n![Kurtosis tools](./kurtosis-tools.png)\n\nDora is one of the most commonly used tools for the Beacon Chain. Here is how its interface looks like:\n\n![Dora](./kurtosis-dora.png)\n\n## Working with Logs\n\nReading logs is an important part of debugging and monitoring the devnet. Logs can be accessed using the CLI:\n\n```sh\nkurtosis service logs -f\n\n# Example\nkurtosis service logs my-testnet cl-1-teku-geth -f\n````\n\nLogs can also be written to a file for further analysis:\n\n```sh\nkurtosis service logs > \n\n# Example\nkurtosis service logs my-testnet cl-1-teku-geth > kurtosis.log\n```\n\nAlternatively, Docker logs can be used to inspect Kurtosis containers:\n\n```sh\ndocker logs \n```\n\n## References\n\n- [Ethereum Package GitHub Repository](https://github.com/kurtosis-tech/ethereum-package)\n- [Kurtosis GitHub Repository](https://github.com/kurtosis-tech/kurtosis)\n- [Kurtosis Official Documentation](https://docs.kurtosis.com)\n- [Kurtosis Deep Dive (EthPandaOps blog post)](https://ethpandaops.io/posts/kurtosis-deep-dive/)\n- [Kurtosis Workshop by EthPandaOps Team (Youtube)](https://www.youtube.com/watch?v=mywpmp2sPt0)\n- [3-minute introduction of running local devnet using ethereum-package by James (Prysm)](https://www.loom.com/share/f7d32d0af14f4f24b63bf3cebfdc796a)\n" }, { "path": "docs/wiki/testing/overview.md", "content": "# Testing\n\nEthereum client implementations undergo constant testing on different levels which ensures security and stability of the network. For a decentralized network, ensuring all clients communicate correctly, behave the same way and therefore agree on transaction outcomes as defined by the protocol is indispensable. A difference in a single state transition would cause a network split resulting in finalization failure and many problems for users. To achieve stability, Ethereum clients must undergo rigorous testing against a standardized suite of test cases. \n\nThese tests verify adherence to [execution](/wiki/EL/el-specs.md) and [consensus](/wiki/CL/cl-specs.md) specifications, guaranteeing all clients interpret and execute transactions identically. This rigorous testing also functions as a proactive bug-detection tool that safeguards against network forks (disagreements on the canonical blockchain state).\n\n## Resources\n\n### Walkthrough\n- [Testing & Security Overview](https://www.youtube.com/watch?v=PQVW5dJ8J0c)\n\n### Common test suite\n- [pytest: Python test framework](https://docs.pytest.org/en/8.0.x/)\n- [Ethereum Tests: Common tests for all implementations](https://github.com/ethereum/tests)\n- [Hive: Ethereum end-to-end test harness](https://github.com/ethereum/hive)\n\n### Execution layer tests\n- [Execution Spec Tests: Test cases for execution clients](https://github.com/ethereum/execution-spec-tests)\n- [FuzzyVM: Differential fuzzer for EVM](https://github.com/MariusVanDerWijden/FuzzyVM).\n- [retesteth: Test generation tool](https://github.com/ethereum/retesteth)\n- [EVM lab utilities](https://github.com/ethereum/evmlab)\n- [Go evmlab: Evm laboratory inspired by EVMLAB](https://github.com/holiman/goevmlab)\n- [Collection of execution APIs](https://github.com/ethereum/execution-apis)\n\n### Consensus layer test\n- [Consensus Spec Tests](https://github.com/ethereum/consensus-specs/tree/dev/tests)\n\n### Tools for testing chains\n- [Assertoor: Ethereum Testnet Testing Tool](https://github.com/ethpandaops/assertoor)\n- [Ethereum package: Testnet deployer](https://github.com/kurtosis-tech/ethereum-package) (Recommended for beginners)\n\n### Dashboards\n- [Hive test results](https://hivetests.ethdevops.io/)" }, { "path": "docs/wiki/wiki-intro.md", "content": "\n\n# Welcome to Protocol Wiki\n\nProtocol Wiki is a learning resource for anyone diving into Ethereum protocol, its development and research. It has been created during EPF Study Group as collaborative effort to create a contextual documentation of important domains of the protocol.\n\n## Using the wiki\n\nThe wiki structure follows the design of Ethereum protocol. It's divided into sections mapping to important areas of the protocol and its development. Each section consists of pages covering its most relevant parts and provides a technical overview. Sections and its topics can be navigated in the left sidebar.\n\n> Wiki pages provide a context and explanation but also serve as a collection of external resources covering the topic. Use the resource section at the bottom of each page to learn more about the topic.\n\nTo learn about a specific topic, identify what section it belongs to or use the search bar to find occurrences of the relevant term. If there is an important topic currently missing, open an [issue](https://github.com/eth-protocol-fellows/protocol-studies/issues) to let other know. For contributing yourself, check [contribution guidelines](/contributing.md) first.\n\nThe wiki is written by a community of volunteers and continues to grow. Many pages are marked as _stubs_ and don't yet fully cover the topic.\n" }, { "path": "notes/Chloe_notes.md", "content": "Guest hangout session and lots of interesting topics were discussion with bunch of links. So I briefly summarized the link mentioned in the chat and shared here.\n\n\nGreat resource on Ethereum ecosystem in general\n\n- http://ethereum.org/\n- https://eth2book.info/\n- https://ethresear.ch/\n- https://ethereum-magicians.org/\n\nEth R&D Discord Guidebook\n\n- https://github.com/tvanepps/EthereumDiscordGuidebook\n\nEphemery testnet now support Dencun, which could be used to test validators and blob tx\n\n- https://ephemery.dev/\n\nBlog on how to run an Ethereum node\n\n- https://nownodes.io/blog/how-to-run-an-ethereum-node-a-comprehensive-guide/\n\nEthereum on ARM: Recommended hardware to run a node\n\n- https://ethereum-on-arm-documentation.readthedocs.io/en/latest/quick-guide/recommended-hardware.html\n\nRIG (Robust Incentives Group) topic related links\n\n- https://github.com/ethereum/rig\n- https://www.notion.so/c11382c213f949a4b89927ef4e962adf?pvs=21\n\nCensorship resistance topic related links\n\n- https://toniwahrstaetter.com/\n- https://censorship.pics/\n- https://docs.arbitrum.io/sequencer#unhappyuncommon-case-sequencer-isnt-doing-its-job\n- https://github.com/taxmeifyoucan/p2p-trading/\n\nDev related resource\n\n- https://github.com/eth-protocol-fellows/protocol-studies/blob/main/docs/wiki/dev/developer-resources.md?plain=1" }, { "path": "notes/gorondan.md", "content": "# Goron Dan Notes\n\n## Objectives\n\nThe purpose to joining this program is to get a deeper understanding of the infrastructure that makes everything possible in the application layer, and the directions further, while expanding my protocol knowledge. Also, I have a high interest in understanding how the current work carried on protocol level will impact the application layer in the short to medium term.\nReading the material in the previous EPF programs, I realize that after finalizing EPS and moving into EPF, we will have to become much more technical/practical. To my understanding, that means identifying areas of interest where we can bring our own additions and setting a clear project goal, leading to working on an actual project, with well defined deliverables expectation (improvement/applied research/analyzing tool).\n\n## Areas of Interest\n\n* staking design - I feel that this topic transcends on-going and future protocol development and it will have a palpable impact on the application layer in the short to medium term. Also long term, but that is most likely to be subjected to the [time factor](../docs/wiki/research/roadmap.md#roadmap-overview).\n\n## Potential project\nMy goal is to partake in a project that would propose minimal viable enshrinement of liquid staking. \n\nThe fundamentals were set by Vitalik in this document[ [1]](#resources) and there's one Ethresearch proposal here[ [2]](#resources).\n\nAn example could be: \"Author an EIP and corresponding POC implementation for *Enshrined Operator-Delegator separation*, or *Increasing trustless liquid staking viability\"*.\n\n### Possible proposed work:\n* add in-protocol validator **quick staking key** (Q key) alongside the currently required **persistent staking key** (P key)\n* adapt protocol to take into account the P+Q public validator key format (possible directions):\n - adapt slashing design and/or\n - adapt [inclusion lists](../docs/wiki/research/inclusion-lists.md) design\n\n### Challenges\n* the project should not affect validator economics, but propose simple protocol tweaks that would work towards minimal viable enshrinement of liquid staking.\n* enshrining has it's limitations [[3]](#resources)\n* questions to be asked and answered during project:\n - would the implementation of the project's proposed spec changes actually improve the staking scene? \n - large numbers of delegators part of big staking pools could create anomalies in the network(late block production, missed attestations). A tool for testing that is part of a prior EPF work in cohort three [[4]](#resources).\n - how would the proposed changes interact with other ongoing developments like increasing the MAX_EFFECTIVE_BALANCE(EIP-7215)[ [5]](#resources), [light-clients](../docs/wiki/research/light-clients.md), SSF, etc? would it have an overall positive impact and mix well with current/previous protocol improvements?\n\n### Possible expected effects\n* short-medium term: \n - improve protocol and staking pools decentralization\n - allow staking delegators to participate in consensus in a meaningful way; \n* medium-long term: \n - paving the way to de-risking staked ETH\n - paving the way for SSF\n\nI'm looking forward to hearing from interested fellow students and willing mentors, in order to explore the best project track 🤝\n\n## Resources\n[[1] Protocol and staking pool changes that could improve decentralization and reduce consensus overhead](https://notes.ethereum.org/@vbuterin/staking_2023_10)\n\n[[2] Unbundling staking](https://ethresear.ch/t/unbundling-staking-towards-rainbow-staking/18683)\n\n[[3] Should Ethereum be okay with enshrining more things in the protocol?](https://vitalik.eth.limo/general/2023/09/30/enshrinement.html#what-do-we-learn-from-all-this)\n\n[[4] On-chain analysis of staking pools attestations](https://github.com/eth-protocol-fellows/cohort-three/blob/master/projects/On-chain-analysis-of-staking-pools.md)\n\n[[5] EIP-7215 current research](../docs/wiki/research/roadmap.md#current-research)" }, { "path": "notes/gorondan_MVEls_notes.md", "content": "# MINIMUM VIABLE ENSHRINEMENT OF LIQUID STAKING (MVE-LS)\n\n## What is MVE-LS?\nMVE-LS is the minimum set of measures that could be implemented at protocol level in a short period of time (preferably in parallel with other congruent upgrades being developed and evaluated for inclusion in Pectra hard fork). \nIt is the quasi-equivalent of Level 1/3 as per the [Rainbow Staking POC](https://ethresear.ch/t/unbundling-staking-towards-rainbow-staking/18683/8) - Enshrined Operator-Delegator separation:\n\n```\n[...]enshrining some separation between operator and delegator[...] might be ok with some level of complexity. We could call a basic operator/delegator separation Level 1 [...]\n```\n[[1]](#resources)\n\n## Feasibility \n* Necessity \n - There are risks in relying too much on the social layer and morality to protect the protocol against centralization in the staking scene and countering the emergence of a dominant LST with its afferent perils\n - We need an interface to integrate further “protocol services” in a plug-and-play manner\n - Limitations of current staking-design to ensure future competitive participation of solo stakers in different categories of protocol services (i.e. economic value and/or agency)\n - Ethereum needs good trade-offs to SSF\n* Opportunity \n - enshrining a variant of the already established staking model with two classes of participants: delegators (stakers) and node operators\n - enshrining some measure of operator–delegator separation concomitant with other EIPs that are debated and developed right now, could leverage a lot of the work currently done towards specifying these EIPs:\n - EIP-6110 [[5]](#resources) allows for an in-protocol mechanism of deposit processing on the Consensus Layer. Also it will add in-protocol mechanism by which large node operators can combine validators without cycling through the exit and activation queues.\n - EIP-7251 [[4]](#resources) will allow a single message to carry more stake; enshrining the operator delegator separation would provide a way for the protocol to functionally distinguish “operator stake” from “delegator stake” on such a message.\n\n## Feature set\n\n| **FEATURE** | **title** | **description** | \n| :----------: | :-----------: | :-----------: |\n|Feature 1|enshrine Quick Staking Key (Q key)|Allow validators to provide two staking keys: the persistent key (P key) and the quick staking key (Q key) - a smart contract that, when called, outputs a secondary staking key during each slot\n\n```\nThe protocol would give powers to these two keys, but the mechanism for choosing the second key in each slot could be left to staking pool protocols.\n```\n[[2]](#resources)\n## Implementation POC\nMVE-LS POC can be done on top of EIP-6110 specification for future validator deposits and of EIP-7251 for backward compatibility (hard fork) \n\n## Resources\n[[1] Unbundling staking](https://ethresear.ch/t/unbundling-staking-towards-rainbow-staking/18683)\n\n[[2] Protocol and staking pool changes that could improve decentralization and reduce consensus overhead](https://notes.ethereum.org/@vbuterin/staking_2023_10)\n\n[[3] Should Ethereum be okay with enshrining more things in the protocol?](https://vitalik.eth.limo/general/2023/09/30/enshrinement.html#what-do-we-learn-from-all-this)\n\n[[4] EIP-7215](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7251.md)\n\n[[5] EIP- 6110](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-6110.md)\n\n" }, { "path": "notes/mario.md", "content": "# Hangout call #1\n\nOn Thursday, March 7 we are having our first EPFsg hangout. Looking forward to finally speak to folks from the group. \n\nUse this folder to create your own notes during the call, collect resources and share them with others. \n\nThe call is informal but will be divided to main parts:\n\n- Breakout rooms\n- Wiki work in progress\n- Free chat\n" }, { "path": "notes/steven_notes/PBS.md", "content": "# Proposer-builder separation(PBS)\n\n## Introduction\nBrief overview of PBS, emphasizing its importance for Ethereum's scalability and decentralization.\n\n\n## Why PBS?\n### Foundation for Danksharding\n PBS plays a crucial role in the Danksharding proposal, which aims to scale Ethereum's throughput to over 100,000 transactions per second. Achieving such a level of efficiency in block building necessitates more sophisticated hardware, potentially sidelining solo stakers due to increased costs. PBS addresses this by enabling a specialized, centralized block building process that handles high transaction volumes, while simultaneously allowing block proposers to operate with less hardware. This division of labor not only optimizes transaction processing but also lowers the entry barrier for validators, supporting a more decentralized and inclusive network.\n\n The idea \"**centralized block builder and highly decentralized block proposer**\" is mentioned by Vitalik: [Endgame](https://vitalik.eth.limo/general/2021/12/06/endgame.html).\n\n\n### Enhancing Anti-Censorship Measures\n- By separating the duties of block builders and proposers, PBS makes it significantly more challenging for builders to censor transactions, thus promoting a freer and more open transaction inclusion process.\n- It also protects against external pressures from powerful organizations that may seek to influence transaction selection, as block proposers do not possess knowledge of the transaction contents within the blocks they broadcast. This ignorance ensures a higher degree of impartiality and resistance to censorship\n\n### Economic Realignment of MEV\n PBS aims to democratize the benefits of Maximal Extractable Value (MEV) by dismantling the disproportionate advantages held by institutional operators over individual stakers. By updating the economic incentives associated with MEV, PBS seeks to level the playing field, ensuring that the rewards of network participation are more equitably distributed among all contributors, regardless of their scale.\n\n## PBS Implementation Approaches\nThere are two main implementations of PBS: [MEV-Boost](https://github.com/flashbots/mev-boost/) and Enshrined PBS (ePBS).\n\nThe key difference between MEV-Boost and ePBS lies in their approach and integration level within the Ethereum ecosystem. MEV-Boost operates as an external service that validators can opt into, providing a bridge between validators and a competitive marketplace of block builders. It's a practical solution that can be implemented without altering Ethereum's core protocol.\n\nOn the other hand, ePBS represents a more integrated approach, aiming to incorporate the proposer-builder separation directly into Ethereum's protocol. This would require consensus and implementation at the Ethereum protocol level, offering a more unified and potentially more secure framework for managing the roles of block construction and proposal.\n\n### MEV-Boost\nHere's a diagram illustrate how MEV-Boost works as an sidecar software with Ethereum from [MEV-boost github repo](https://github.com/flashbots/mev-boost/), where more detailed information can be found.\n\n![mev-boost architecture](https://raw.githubusercontent.com/flashbots/mev-boost/54567443e718b09f8034d677723476b679782fb7/docs/mev-boost-integration-overview.png)\n\n### ePBS\nThere are [many proposed implementations](https://github.com/michaelneuder/mev-bibliography#specific-proposals) of ePBS, nevertheless there had not been a final conclusion or universally accepted design for ePBS within the Ethereum community. The process of developing such a foundational change involves careful consideration of numerous factors to ensure that the benefits of proposer-builder separation are realized without introducing new vulnerabilities or inefficiencies\n\n[Why enshrine Proposer-Builder Separation](https://ethresear.ch/t/why-enshrine-proposer-builder-separation-a-viable-path-to-epbs/15710) present the arguments for and against ePBS, layout design goals of an ePBS mechanism, illustrate several ePBS designs such as Two-Block HeadLock and Optimistic Relaying.\n\n\n## Progress\nThe evolution of Ethereum Proposer-Builder Separation (ePBS) has seen the development of two distinct methodologies towards its full realization:\n1. Top-Down Approach: This standard procedure starts with community discussions, leading to a consensus and specification development, followed by client team implementations. It's a structured approach ensuring coordinated progress towards ePBS.\n\n2. Bottom-Up Approach via MEV-Boost: Given MEV-Boost's adoption in about 90% of Ethereum blocks (source), this method suggests incremental ePBS integration by evolving MEV-Boost's relay infrastructure. It allows for a gradual shift towards ePBS without immediate, widespread changes to consensus software.\n\n## Further Reading\n[Further Reading](https://ethereum.org/en/roadmap/pbs/#further-reading)\n" }, { "path": "notes/steven_notes/weekly_updates_1.md", "content": "# Weekly Update #1\n\n> Discover more about [Steven's EPF journey](https://hackmd.io/@qz8qnEAKSzCXkPyX1NRrAg)\n\n## Objectives\n\nThis week's focus revolves around laying a foundational understanding of Ethereum's architecture, particularly emphasizing the Execution Layer and Consensus Layer. To achieve this, I plan to engage with a curated selection of educational resources. Additionally, I aim to delve into the intricacies of the Engine API and explore the Ethereum development roadmap to identify areas that pique my interest the most. Detailed objectives include:\n\n- **Understanding the Execution and Consensus Layers**: \n - Review and comprehend the basic concepts of the Execution Layer and Consensus Layer through selected learning materials. \n\n- **Exploring the Engine API**:\n - Document the functionality and workflow of the Engine API, highlighting the code flow and key operations. This exploration aims to clarify how the Engine API facilitates interaction between the Execution and Consensus Layers.\n\n- **Researching Ethereum's Roadmap**\n - Investigate the current roadmap for Ethereum's development, with the objective of understanding the strategic goals and upcoming enhancements. This research will focus on identifying the initiatives that significantly contribute to Ethereum's improvement and selecting the ones that align with my areas of interest for deeper exploration.\n\nBy accomplishing these objectives, I hope to build a solid foundation of knowledge that will support my journey towards becoming a core contributor to the Ethereum ecosystem.\n\n## Output\n**Understanding the Execution and Consensus Layers**\n\nThe primary resource I utilized this week was the [Eth2 Book on Consensus Preliminaries](https://eth2book.info/capella/part2/consensus/preliminaries/). Having previously read it, I skimmed through it again, paying special attention to several new sections that have been added. This book provides a solid foundation in understanding the intricate details of the Ethereum 2.0 consensus mechanism, and I highly recommend it to all developers interested in Ethereum's technical underpinnings.\n\n**Exploring the Engine API**:\n\nA particularly helpful resource was the blog [Engine API: A Visual Guide](https://hackmd.io/@danielrachi/engine_api#Block-Building). I explore the Prysm codebase with this blog and below are some annotated insights into the source code:\n\n- **prysm client initialization flow: prysm/cmd/beacon-chain/main.go**\n 1. app.New() // cli application/instance\n 2. parseFlags\n 3. `app.before(ctx)`\n 4. `app.Action(ctx)`\n - node.New() // register every required services\n - `startNode(ctx, cancel)`\n - beacon, err := node.New(...) // beacon node handles the lifecycle of entire system\n - beacon.Start()\n - beacon.services.StartAll() // initialized each service in order of registration\n - p2p\n - initialSync\n - backfill\n - attestations\n - blockchain\n - ...\n 5. `app.After(ctx)`\n\n- **engine api interface: /prysm/beacon-chain/execution/engine_client.go**\n```\ntype EngineCaller interface {\n\tNewPayload(ctx context.Context, payload interfaces.ExecutionData, versionedHashes []common.Hash, parentBlockRoot *common.Hash) ([]byte, error)\n\tForkchoiceUpdated(\n\t\tctx context.Context, state *pb.ForkchoiceState, attrs payloadattribute.Attributer,\n\t) (*pb.PayloadIDBytes, []byte, error)\n\tGetPayload(ctx context.Context, payloadId [8]byte, slot primitives.Slot) (interfaces.ExecutionData, *pb.BlobsBundle, bool, error)\n\tExecutionBlockByHash(ctx context.Context, hash common.Hash, withTxs bool) (*pb.ExecutionBlock, error)\n\tGetTerminalBlockHash(ctx context.Context, transitionTime uint64) ([]byte, bool, error)\n}\n```\n\n- **validator lifetime**\n 1. receive block from other validators: **/prysm/beacon-chain/blockchain/receive_block.go**\n 1. extract execution payload\n 2. **s.validateExecutionOnBlock**: call engine_newPayload\n 3. **s.postBlockProcess**: call engine_engine_forkchoiceUpdated\n 2. propose block: **/prysm/beacon-chain/rpc/prysm/v1alpha1/validator/proposer.go**\n 1. **vs.ExecutionEngineCaller.ForkchoiceUpdate**: call engine_forkchoiceUpdated\n 2. **vs.ExecutionEngineCaller.GetPayload** : call engine_getPayload\n 3. compute root and propagate block\n\n\n**RoadMap**\nFor reference: [Ethereum Roadmap](https://ethereum.org/en/roadmap/)\n\nThe roadmap aims at bringing four benefits for users:\n- Cheaper transactions(Done partially)\n - Proto-Danksharding (Done recently in EIP-4844)\n - Danksharding\n - Decentralizing rollups\n- Extra security (need to finalize a specification and start building prototypes)\n - Single slot finality \n - DVT \n - Proposer-builder separation \n - Secret leader election\n- Better user experience\n - Account abstraction(EIP-4337)\n - Nodes for everyone\n - Verkle tree\n - Statelessness(weak statelessness preferred but rely on Verkle tree and Proposer-builder separation)\n - Data expiry(portal network is an option)\n- Future proofing (still in the research phase)\n - Quantum resistance\n\n**I'm currently more interested in PBS and Portal network and more research is needed before final decision.**" }, { "path": "notes/steven_notes/weekly_updates_2.md", "content": "# Weekly Update #2\n\n> Discover more about [Steven's EPF journey](https://hackmd.io/@qz8qnEAKSzCXkPyX1NRrAg)\n\n## Objectives\n\nThis week I will explore more on two topics: PBS(proposer-builder separation) \nand Portal network, which are pivotal to understanding the concepts of \"the Splurge\" and \"the Purge\", respectively.\n\n![Ethereum_phases](https://hackmd.io/_uploads/Byq5uOlxC.jpg)\n\nI need to:\n- **develop two comprehensive research documents**\n - For each topic(PBS and Portal network), I will prepare a detailed research document to cover the following aspects:\n - why it should be done\n - how it can be done\n - current progress and future work\n\n- **select one as EPF project based on research**\n - Based on the insight gained from the research documents, I will make an decision on which topic to pursue. The selection will include factors such as potential impact, feasibility, and personal interest\n\n\n\n## Output\n### PBS\nMy notes: [PBS Overview](/notes//steven_notes/PBS.md) \n\n### Portal Network\n[The Portal Network](https://ethereum.org/en/developers/docs/networking-layer/portal-network/). This resource from the official Ethereum website provides an excellent explanation of the Portal Network, addressing pertinent queries and serving as a valuable reference point.\n\n## Decision and Next Steps\nBoth the Proposer-Builder Separation (PBS) and the Portal Network hold substantial importance for the future of Ethereum, sparking a keen interest in contributing to their development. However, upon careful consideration, I have decided to focus on the Portal Network for the following reasons:\n- **Stage of Development**: ePBS remains in the research phase, representing a vast undertaking that could extend over one to two years. Although I plan to monitor its progress closely, the current stage presents challenges for immediate involvement\n- **Opportunity for Contribution**: The Portal Network already boasts a detailed specification and is supported by three client implementations, yet it lacks a Go-based client. This gap presents a unique opportunity for me to contribute by developing a Go client, leveraging my skills and interests.\n\nStarting next week, my endeavors will be directed towards gaining a deeper understanding of the Portal Network. Concurrently, I will continue to enhance my knowledge of Geth and related technologies, balancing my commitment to contributing meaningfully while expanding my expertise.\n" }, { "path": "notes/wiki_contributors_meeting/2024-04-18-meeting-1.md", "content": "# Wiki Contributors Meeting #1 - April 18, 2024 (5PM UTC)\n\n## Agenda\n\n- Current state of the wiki, issues, PRs\n- Feedback from contributors, share your perspective\n- Discuss and come up with tasks to accomplish, filling content gaps\n- Future of the wiki\n\n## Participants\n\n- Angus\n- Aritra\n- Gorondan\n- Kira\n- Mario\n- meldsun0\n- Nagu\n- Rahul\n- Rory\n- Siddharth\n\n## Notes\n\n### Current State of the Wiki and Contributing\n\n- Mario shared the goals behind developing EPF WIKI. Mario noted the high quality of contributions thus far.\n- Kira sees the wiki as a repository to document their learning. They are currently working on Prism client and consensus layer. Overlapping content during collaboration was identified as a point of friction.\n- Gorondan emphasized the importance of improved collaboration to expedite completion of open PRs.\n- Aritra suggested that pre-agreed upon document flow could lead to better collaboration.\n- Rory wondered how to encourage more people to contribute.\n- meldsun0 suggested potential reasons for contributor hesitancy, such as difficulty using GitHub. They proposed reaching out to encourage more active participation.\n- Mario acknowledged that the contributing.md document might be overwhelming. He asked for further input on the state of the wiki and contributing experience.\n- Kira suggested checking for existing content before contributing new sections. Mario confirmed this will be highlighted in the contributing.md document.\n- The landing page was discussed as a potential barrier to entry. Mario suggested improvements and mentioned promoting the wiki once closer to completion.\n- Gorondan proposed promoting the wiki to raise awareness and encourage contributions. Mario agreed and suggested a meetup to share the project.\n\n### Previous Cohorts and Contributing Experience\n\n- Rory inquired about previous cohort involvement with the wiki. Mario confirmed this is the first cohort to work on the wiki. While other cohorts have created content, it's not centrally collected. He hopes this wiki serves as a foundation for future cohorts.\n- Rory suggested mimicking the core developer experience with breakout rooms for wiki contribution.\n- meldsun0 proposed assigning section ownership. Mario found it an interesting idea but unsure if anyone's willing to take ownership.\n- Aritra expressed interest in owning the consensus layer section, finding the approach appealing.\n- Gorondan suggested approaching the wiki as a collaborative project to collectively complete it. Mario agreed and encouraged volunteers to claim responsibility for sections.\n- Rory expressed interest in contributing to the testing section.\n\n### Open Issues, Roadmap, and Content Gaps\n\n- Gorondan mentioned his PR on the roadmap and received positive feedback from Mario, who encouraged continued work on it.\n- Mario suggested working on open issues and identifying content gaps. While \"boring\" topics like client overviews are essential for beginners, focusing on these areas was suggested.\n- Gorondan expressed willingness to work on client documentation.\n- Rahul suggested to include a section about EIPs. Mario confirmed he would add that.\n- Sid mentioned el-architecture as a topic he is working on.\n- Kira indicated they would submit PRs for sections of interest shortly. Mario mentioned opening more issues later. Everyone was encouraged to comment on existing issues or create new ones.\n- Mario acknowledged the importance of bridging basic gaps, mentioning a dependency tree. He emphasized covering foundational topics to provide a starting point for users.\n- Originally hoping to have the wiki ready by the end of the study group, Mario acknowledged it might take longer. A target of mid-May was proposed to assess progress and prepare for public promotion.\n\n### Closing Thoughts\n\n- To maintain the wiki, Mario suggested continuing these calls, proposing bi-weekly meetings. Timezone preferences were discussed, with most favoring bi-weekly meetings.\n- Gorondan raised the challenge of using links in open PRs and suggested faster PR merging. Mario explained the option to fetch updates from upstream but acknowledged considering faster merging. He identified himself as a potential bottleneck and encouraged pinging him to expedite reviews.\n- Nagu suggested using reference wikis as a last pass for additional edits once the content is mostly complete. They also inquired about delegating tasks from Mario's workload.\n- Mario welcomed assistance with reviewing existing content and onboarding new contributors.\n- Nagu proposed cross-posting PRs in the wiki-writers group to encourage reviews. Mario confirmed the GitHub bot already serves this purpose.\n\n## Next Steps\n\n- Interested contributors can claim ownership of sections.\n- Finalize the meeting schedule, aiming for bi-weekly.\n- Contributors are encouraged to open issues for missing content.\n\n## Meta\n\nFor every meeting, create a new file inside `/notes/wiki_contributors_meeting` using the convention `YYYY-MM-DD-meeting-no.md`; eg.`2024-04-01-meeting-1.md`. This helps preserve chronological order when sorting files.\n" }, { "path": "notes/wiki_contributors_meeting/2024-05-02-meeting-2.md", "content": "# Wiki Contributors Meeting #2 - May 02, 2024 (4PM UTC)\n\n## Agenda\n\n- Progress since last call, reflecting on the current state of the wiki\n - Active issues and PRs\n- Sharing the wiki publicly\n - Outstanding tasks before releasing current wiki version\n - Community maintenance and versioning \n\n## Participants\n\n- Asli\n- Gorondan\n- Hopinheimer\n- Kira\n- Manas\n- Mario\n- Nagu\n- Rahul\n- Raa\n- Siddharth\n\n## Notes\n\n- Mario: Welcome everyone. Lets quickly review open pull requests.\n- Mario to Gorondan: Please notify me when your PRs are ready for review.\n- Gorondan: Execution tickets will take me a few days, but #169 can be merged.\n- Mario: Rahul, great work on Formal verification. Ethereum's history is an important topic. The DAO and Parity hack provide important context. Anyone - feel free to pick that up.\n- Mario to Nagu: Thank you for the quick response on SSZ and Merkleization. I'm open to merging it.\n- Nagu: Sounds good.\n- Mario: Gorondan, you've created issue for adding warning artifacts to research pages.\n- Gorondan: I believe it's fair to have a warning that content is subject to change.\n- Mario: I recall discussing with someone that important wiki pages should be future-proof. Feel free to add these warnings to relevant detail pages. Let's also add instructions on using various artifacts to contributing.md so we have it in one place.\n- Siddharth: I'm wondering how to prioritize work, like the block building from week 1. I've been doing a lot of research lately. I was thinking of tackling EL Architecture next week, but it's a huge document. I think we should break it down for easier review.\n- Mario: For things you have ready, feel free to submit a PR. The architecture is crucial for specs. Kira worked on Consensus architecture, so it would be nice if both architectures follow the same structure. The lowest priority would be the Geth thing.\n- Siddharth: Then I'll finish the EL Architecture, specs, and then Geth. Specs are fairly simple. As an aside, I learned a lot from reviewing Geth.\n- Mario: Rory is working on testing.\n- Gorondan: Hopinheimer is working on the protocol design.\n- Mario: Some topics from the proposed protocol design structure are not necessary. I'll comment on the issue. It's important to cover design rationale. It's not covered anywhere.\n- Mario: We should ensure single pages are lean for maintainability.\n- Gorondan: Light clients page is interesting. If we start a page, Dirk can work on it.\n- Mario: There is a stub page. Feel free to open an issue and work on it.\n- Gorondan: Is the page about execution or..?\n- Mario: It's explained in the page. It's just covering an RPC verifier using data from an independent beacon node.\n- Rahul: Protocol overview is a priority for me. I got nerd sniped by Mario's lecture on Linux history and cryptopunks.\n- Mario: The biggest missing piece is testing. We should document hive or different testing mechanisms.\n- Kira: I kind of [wrote a condensed version of the yellow paper](https://hackmd.io/@kira50/H1O4tO6WC). In case someone would like to review it.\n- Mario: Very cool. We should have it in the wiki. Feel free to open an issue and work on it.\n- Hopinheimer: I have an open issue on dev-p2p and am planning to catch up with it this weekend.\n- Mario: I would suggest checking with Angus. He worked on networking and consensus and spent a lot of time on dev-p2p.\n- Hopinheimer: Sure. I'll ping him.\n- Kira: Prysm has a really cool search bar. Can we have something similar I worked on?\n- Mario: We always had a search bar. With the new UI, it's improved. If there's nothing else, I think we're ready to share it! Feel free to share the wiki publicly. With EPF starting soon, I think the wiki should serve as a good learning resource. Also, should we version releases? We want to offer people more stable content and maybe archive it. Thoughts?\n- Rahul: We could semver it.\n- Gorondan: Maybe we should do bi-weekly updates until it's mature, then after 1.0, we could version it.\n- Mario: I think most changes are behind us, so it makes sense to somehow track changes. Two weeks seems like a big window. I think we should do a weekly release.\n- Kira: We could version based on Ethereum forks?\n- Raa: We could follow semver and have a mapping with Ethereum releases. New pages can increment the minor or patch version.\n- Rahul: We could use Ethereum fork names followed by dates as versions, like how [evm.codes](https://www.evm.codes/) does it.\n- Mario: Currently, Josh and I are the only maintainers of the GitHub repo. I'd like to have one or two more people. I vote Rahul and one more person. I'd like to add two reviewers to the workflow. Over time, we can have 3 or 4 people. We can also have a deployment action in GitHub. We'll reach out to some contributors for rewards. Details soon.\n- Mario on upcoming conferences: EthBerlin is a hackathon. Prague is my home conference, now quite big with over 1000 people. You're all invited. I could get you some tickets. Then there's ETHCC. We'll focus on technical conferences. Lastly, I'll create a recurring event for this meeting every two weeks from now. Feel free to send me your email.\n- Asli: I couldn't contribute much but looking forward to this.\n- Mario: Feel free to get started. I'll see you in two weeks. Goodbye.\n\n## Next Actions\n\n- Gorondan: Follow up on PR readiness.\n- Siddharth: Submit PRs for EL Architecture and specs.\n- Kira: Work on open issues and maybe covering yellow page overview.\n- Hopinheimer: Catch up on dev-p2p issue and involve Angus.\n- Everyone: Share thoughts on versioning and release strategy.\n- Mario: Reach out to potential additional maintainers and reviewers for the GitHub repo. Public launch of the wiki. Set up deployment action. Organize rewards for contributors.\n" }, { "path": "notes/wiki_contributors_meeting/2024-05-16-meeting-3.md", "content": "# Wiki Contributors Meeting #3 - May 16, 2024 (4PM UTC)\n\n## Agenda\n\n- Progress since last call, reflecting on the current state of the wiki\n - Active issues and PRs\n- Sharing the wiki publicly\n - Continue the conversation on versioning\n - Channels to share the wiki\n\n## Participants\n\n- Asli\n- Gorondan\n- Kira\n- Mario\n- Nagu\n- Rahul\n- Siddharth\n- @meldsun\n\n## Notes\n\nRory is currently working on testing, specifically with an emphasis on hive. Mario stated that Mario Vega is the leading authority on hive, and Rory has already established contact with him regarding that subject. In addition, @faytey will be making a contribution to the testing page. She is acquainted with Rory and they had a meeting regarding the topic one day prior to the wiki contributors meeting. In addition, she desires to make a contribution to the cryptography page.\n\nMario informed that the EPF applications are now open. However, it should be noted that contributing to the wiki and participating in the study group does not guarantee a stipend for the EPF. Nevertheless, all contributors are strongly encouraged to apply, as it can still be advantageous even if they do not receive a stipend.\n\nVarun asked about a page dedicated to attacks and requested clarification on the specific types of attacks it should include. Mario suggested including information about the Shanghai attacks and organizing the content across multiple pages. The History page should make a reference to the incidents page, which in turn should make a reference to the evolution page.\n\nKira stated that he is currently engaged in the development of consensus layer pages and anticipates having a deliverable by the following week.\n\nAfter completing his project proposal, Dan will subsequently focus on working on the SSF page. In addition, Dan raised the concern regarding the incorrect rendering of tables. A front end developer, who is familiar to him, suggested setting the CSS property overflow to auto. Mario suggested that the solution should be shared in a publicly accessible manner, such as through a Github branch or pull request.\n\n@asli suggested a solution for the builders/searchers issue. A pull request will be initiated shortly to address this.\n\n@hopinheimer is currently working on the protocol design page, and @meldsun will also be involved in this task.\n\nMario raised the concern that the sidebar disappears on smaller screens, and the close button does not appear on certain devices. In addition, he stated that the issues should be included in the release version of the GitHub project and recommended that we create a release milestone prior to the initiation of the EPF. Subsequently, he proposed the idea of sharing the wiki and inquired about the preferred communication channels to be utilized. Dan proposed utilizing our personal channels and networks to distribute the wiki, and he plans to set up farcaster for wider dissemination. Mario mentioned that he has already shared it on Twitter, in face-to-face conversations with core developers, and in the R&D discord channel. And As Dan suggested, we should also individually share it through our own channels and accounts. In addition, Mario conveyed some of the feedback, which was predominantly positive, but there were a few negative comments regarding a perceived LLM influence in certain content.\n" }, { "path": "notes/wiki_contributors_meeting/2024-06-20-meeting-4.md", "content": "### **Meeting Minutes:**\n\n**Attendance**\nMario\nRory\nDanGoron\nSid\nHopinheimer\nKira\nGlory Agatevure (gconnect)\nZarathustra\n\nMario - First [milestone](https://github.com/orgs/eth-protocol-fellows/projects/1/views/2?filterQuery=), idea was to finish before last week. We are almost there. I edited project status today again to reflect latest changes. Idea was to finish before cohort. You can see Backlog, In Progress and Done. Great job on Done page! And kudos to Kira for Consensus Layer Wiki page. Rahul's work on protocol review is in progress...Raa to help? Otherwise Rahul will take over. Mario asked Rory about Testing backlog. Been tied up with EPF project/research but will continue adding to Testing page this weekend. My EPF project revolves around Testing so this makes it easier.\n\nMario - Do we like the Kanban board, this style and milestone tracking progress?\n\nKira - I think this is great and I like reviewing so we have a better view. DanGoron agrees also.\n\nMario - Gives me better overview of what issues, PRs are coupled and I tried to keep it the same. Keep PR and Issue coupled. We can change the dates if we want to be precise.\n\nDanGoron - Regarding dates, we should keep them loosely, we all will contribute but it’s finding the time is more difficult now. Keeping timeline loose seems like the best way.\n\nMario - EPF people coming in, let me look into current PRs as well. Some PRs open from other people who are not here. Fuzzing page….Fuzzing could be integrated into Testing? (Rory to take this on). Dan you opened up an issue you wanted to bring up on the call?\n\nDanGoron - Wanted to find time to finish roadmap. Last three \"-urges\" that need to be completed and thought I hoped other Fellows would want to contribute, used same structure to fill in. Hopefully I can attract Fellows to join and ask for review, otherwise if I have time I will finish myself.\n\nMario - On one hand, I think it’s great if Fellows come and contribute. This content is mostly for them, but also they are focused on working, learning. I was hoping first two weeks people contributing, or EPF focused on fellowship projects, they shouldn’t work on wiki as it may be viewed as less of a priority. First few weeks might be different to keep up with the pace, absolutely no worries if you are focusing on something else.\n\nDanGoron - I do it out of passion so it’s only matter of finding the time. Very nice project Mario that you started and that we contribute to!\n\nMario - I’m pushing for people to use it and somehow people also ignore it.\n\nDan - Referring to the wiki in our weekly updates could be good practice. Use it and tell others to use it.\n\nMario - My observation, I saw in some updates people looking into wiki articles. Then I see questions from people that are answered on wiki. We were explicit about it, I sent people directly to the wiki. I’m not sure how people see it, let’s ask a poll in the next call or fellowship chat, \"do you have any feedback for us?\"\n\nDanGoron - There are Fellows that joined just recently and they do not, might not, spend a lot of time reading about what happened in EPF before they came in.\n\nMario - Will post in Protocol chat for people to be aware of it and give us issue if there’s anything wrong with it.\n\nSid - It was information overload in the first few weeks too.\n\nDanGoron - Definitely a learning curve there. I’ve also known what I want to work on since I joined the study group. The meeting with the first office hours made me realize we need to think more holistically. I try to assimilate as much as possible before diving in. V2 something we start advertising or v1?\n\nMario - Have our own serenity? We can do this but I would keep this v2 thing for later, maybe next year’s study group. I don’t want to take too much resources but also the difference we can make in the content is not huge. There are gaps we have to fill but I would still have it v1.1. Not much difference to call it v2. I would like to have v2 but let’s see how it goes in the coming months. Let’s keep it like this. Gives me ptsd from serenity. :)\n\nMario - When I merge the main to the wiki pages branch, I just name it after the week, the day it was done. 8 June version is just four comments behind. I was waiting for some updates but I can push it now if there is nothing merging soon. Should I call it something else or should i keep it as the date naming? Maybe we can call this 1.0. Going with semVer. Do we want to start with 1.0.0? Still going to add date just for reference, push and wiki pages now updated. You should see latest comment there. Make an archive and release it in the GitHub releases. But right now GitHub deployment is running. Just deployed! Also wait for Rahul’s review or if anyone else wants to post a review there.\n\nKira is addressing comments on the CL PR today\n\nSomebody wanted to create table for CL clients based on diversity site.\n\nZarathustra just joined!\n\nMario addressing this new [issue](https://github.com/eth-protocol-fellows/protocol-studies/issues/295). Frontend is blocked by YouTube now. I wanted to avoid YouTube ads and now they are blocking it. If you want to create GitHub actions workflow.\n\nZarathustra - I can do this (responding to his issue).\n\nMario - Reminder not to prioritize EPS wiki work compared to EPF itself. Going to go into hotfix of 0.1.0.\n\nMario - Anything I missed from agenda?\n\nSid - [Mayowa](https://github.com/MayowaObisesan) messaged me about contributing to EL specs. Very little content in EL specs presentation we have so I brought him in. He might be doing that. His Discord is: blessed07\n\nMario - I could have shilled Contributor meeting.\n\nGlory Agatevure (gconnect) - Introduction. Newcomer! Where can I contribute?\n\nMario - Read through the EPF wiki, as you look into it you see articles that are just stubs, any of these missing gaps, you can write your own page on it. Open a PR and contribute. Also existing pages might miss details so you can contribute to existing pages based on what you read there. Look into issues and look into wiki!\n\nMario - Before we finish, for our next call, what do we think about schedule? In two weeks is EthCC, so maybe in three weeks from now? But could also do in person.\n\nNext contributor meeting will be 11 July!\n" }, { "path": "notes/wiki_contributors_meeting/2024-07-25-meeting-5.md", "content": "# Wiki Contributors Meeting #5 - Jul 25, 2024 (3 PM UTC)\n\n## Agenda\n\n- State of the wiki; items in progress since the last call\n- Clarify Purpose and Intent of Source Code Mirror #297\n- EPF contributions\n\n## Participants\n\n- Caleb\n- Dan\n- Glory\n- Hopinheimer\n- Katya\n- Kira\n- Mayowa\n- Mario\n- Rahul\n- Sid\n\n## Notes\n\n**Mario**: We released wiki [version 1.0.2](https://github.com/eth-protocol-fellows/protocol-studies/commit/ef0b7597261dde7706a2e5f5a34b53b74b530d0d) with the history page, DHT, and information about Grandine. Contributions have slowed down a bit, but that is expected because folks are busy with EPF. There are several pull requests pending. Let's start with Kira's pull request on the consensus layer.\n\n**Kira**: I have considered most feedback and think the PR is ready for review.\n\n**Rahul**: It looks good to me.\n\n**Mario**: I will review it once more and merge it. I think the spell check is broken.\n\n**Kira**: I fixed it in my PR.\n\n**Mario**: Great. I think the style guide can be a separate page.\n\n**Rahul**: Agreed. I will create a new page for it.\n\n**Dan**: I think the roadmap is still open, but it is a good first issue for new contributors.\n\n**Mario**: Agreed. We should get new contributors to work on it.\n\n**Dan**: Maybe we should let EPF fellows know that they could contribute their work to the wiki.\n\n**Mario**: Yep. I don’t think it’s too much overhead.\n\n**Katya**: Propose it in the office hours. The first call where it was mentioned had introductions, so it’s possible that folks missed the part about contributing to the wiki.\n\n**Mario**: Yeah, we need to reiterate the message.\n\n**Rahul**: At the very least, we could ask folks to create an issue about their project and dump resources, allowing other contributors to work on it.\n\n**Dan**: Reviewing pull requests is a bottleneck. How can we get more contributors?\n\n**Mario**: Anybody can review PRs, but I agree we need more reviewers.\n\n**Rahul**: Contributors need incentives.\n\n**Mario**: Yes, but we don’t want to promote low-quality contributions. We have aspiring new contributors—Katya and Mayowa.\n\n**Katya**: I would love to contribute about Kurtosis and Grafana. I have some cheat sheets that I can share, extracted from videos that really save time.\n\n**Mario**: We would love to have that. Feel free to issue and create a PR. It’s fully permissionless. It overlaps with DevOps, so maybe we should create a separate page.\n\n**Dan**: Tim recently published [EIP 7723](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7723.md) about activation on an EIP.\n\n**Mario**: We don’t have the EIP process documented. We should create one based on [Tim’s talk](https://www.youtube.com/watch?v=5L9UUCL7bzI). There is also a [great blog post](https://medium.com/ethereum-magicians/comprehensive-guide-on-writing-and-submitting-an-eip-9474163771f0) that discusses this, though it could be a little outdated.\n\n**Caleb**: I'm working on EPBs with Kira. I realize that most people don’t know how to start with EIPs. I would like to write an article on how to implement an EIP.\n\n**Mario**: I think that’s great and even more important than proposing an EIP itself. Please open an issue.\n\n**Hopinheimer**: Asking core devs for advice on getting started would also be valuable. I would like to gather some feedback and include that in the wiki.\n\n**Mario**: Yeah, we are doing AMAs as part of EPF office hours; we could include that as part of a wiki page. There is also a great [talk by Danny Ryan](https://streameth.org/devconnect/watch?session=65b8f8cfa5b2d09b88ec114b) that might be useful.\n\n**Dan**: On that note, we should collaborate with [Ethereum Cat Herders](https://www.ethereumcatherders.com/) and [Pooja](https://twitter.com/poojaranjan19). She is very active.\n\n**Mario**: Yes, we should have Pooja do an AMA. Also, feel free to suggest guests for upcoming AMAs.\n\n**Mario**: Glory, do you have any comments on your contribution?\n\n**Glory**: I will continue working on the assigned issue.\n\n**Mario**: Regarding mirroring, I could ask EF DevOps to add the wiki to their mirroring workflow. But we should also look into something like [Radicle](https://app.radicle.xyz/nodes/seed.radicle.xyz).\n\n**Dan**: I could help you with that.\n\n**Mario**: Sounds great. That’s all for now. Thanks, everyone.\n" }, { "path": "notes/wiki_contributors_meeting/2025-01-23-meeting-6.md", "content": "# Wiki Contributors Meeting #6 - Jan 23, 2025 (5 PM UTC)\n\n## Agenda\n\n### Intro \nMario drops some alpha about the new SG format ✨:\n\nWhile contributing will be permissionless, as always, this time, wiki-contributors will be invited to be the reviewers of new content produced by the SG students. In a way, the wiki-contributors will be the mentors of the 2025 EPS students, as protocol devs are the mentors of EPF fellows. Mario will coordinate and do the heavy lifting, but wiki-contributors are invited to assist. Also, contributors will probably be invited to conferences and meetups.\n\n### High-level view of the new SG schedule\n- In the first part, new students will focus on existing Wiki content, deep diving in different protocol-related topics.\n- In the second part, new students will focus on writing fresh Wiki content, being reviewed by Mario and Wiki-contributors.\n\n### Details on the 2025 SG schedule\n\nEPFsg 2025 cohort will begin in about 3 weeks and run for 8 weeks. \n\n- First 2 weeks: intense study on the existing content\n - 1st week will cover the first 5 weeks of the previous SG, then, the 2nd week will cover weeks 5-10. \n\nMario will publish the actual schedule and content for coordination.\n\n## TODOs before EPFsg starts\nWe should close open issues and merge existing PRs. The focus should be on tying up loose ends rather than spending too much time on writing long content.\n\n### Existing PRs and issues \n- Mario will work on the Wiki style guide issue, and he remembers that it was decided to only use dark background.\n- Rahul will create a PR for 7702 (Mario recommends to connect with protocol people like Felix to help, the page should not be too complex though).\n- Kira will work on ePBS and FOCIL. Mario suggests that Katya and Dan could help.\n- Hopinheimer and Mario will work on \"Advice for Core Devs.\" However, this page is more relevant for the fellowship, so it's a lower priority. Let's focus on adding more technical content.\n- The roadmap page is still pending. It doesn’t need to be a catch-all page for the roadmap, but it’s important to have it as part of the wiki.\n- Dan will add a stub page for Confirmation rule, and add it to the roadmap. Mario advises to mention it and add minimal content for now (high-level content and links).\n- Hopinheimer suggested adding a page on the gossip protocol. Potuz has published content related to CL networking (RLNC). We might link to Potuz's content (https://github.com/eth-protocol-fellows/protocol-studies/blob/main/docs/wiki/CL/cl-networking.md).\n- PeerDAS is missing. Katya has volunteered to create a page under CL. EthPrague has some resources for PeerDAS. Mario suggests creating a small page, so new contributors have the opportunity to expand on it.\n- Katya has a PR on Kurtosis and there’s a spell-check issue. Rahul will highlight why the spell check fails. Mario commented that the PR should be reviewed by following the tutorial to double-check for any mistakes.\n- Rahul will update the PR for markdown formatting.\n- Chirag is not present, but Mario had a call with him to review his PR.\n- Dan wants to add a consolidated consensus spec as part of the content he's been working on. Mario suggests adding it to the Week 6 development track or perhaps including it in the relevant section of the wiki (CL specs). Also add https://jtraglia.github.io/eth-spec-viewer/ as resource.\n- PR #287 is a UI issue on Mac. Katya will check if the issue is reproducible on Mac (Brave browser).\n- Meldsun has a work-in-progress PR on validator duties. It would be nice to include it as part of CL. It needs some minor updates, so feel free to keep it simple and merge it.\n- Katya suggests that we should create a page for the Beam Chain.\n- Sid has suggested creating a page on EOF. Perhaps create an issue?\n- Bastin suggests adding \"[purified web3](https://purified-web3.box/)\".\n- The recent DevCon has some awesome content, maybe link them.\n- Hopinheimer highlighted an issue with the wiki menu; and PR'ed a fix while on this call. (WHOA 👀)\n\n### Adding new content\nThe Wiki-contributors should start Wiki pages stubs with the intent to cover as many protocol topics as possible and focus on their work on actual protocol development, sticking to reviewing the new content written by students.\nLast year we started from scratch, this time the EPFsg will build on that.\n\n## Wiki improvement proposals\n\nThe sections separators (dotted lines) seems confusing to Katya. \nMario clears it: \n- study group is for mentors and presenters\n- the protocol wiki is for the contributors\n\nThe titles of the groups could be different color says Rahul, or centered (Mario).\n\n## Wiki releases\n\nDan: any plans regarding the wiki releases?\nMario: the main update will be released before the next SG, maybe before the 15th of February.\n\n## Session ends\n\n**Mario**: Great to see each other again and sync on the status of Wiki.\n\n\n\n\n\n" }, { "path": "notes/your-name notes.md", "content": "" }, { "path": "wordlist.txt", "content": "personal_ws-1.1 en 10000 utf-8\naantop\nABI\naccelerometer\naccesedAccountAddresses\naccesedStorageKeys\naccesslistAddress\naccessliststorage\naccesslistStorageKeys\nACD\nACL\naddons\nAdi\nAditional\nAdleman\nAES\nAfser\nAgatevure\naggregative\nAkula\nAleth\nAlisie\nallowfullscreen\nalt\namidst\namongst\nAndreas\nAntonopoulos\nAPI\napi's\nAPIs\nAPS\nArbitrum\nAritra\nArixon\nARPANET\nArvind\nary\nASE\nAshish\nAsli\nasm\nAssche\nAssertoor\nassignees\nasynchronicity\natleast\natomicity\nAttacknet\nAttester\nattesters\nattestors\nauth\nautoplay\nAVS\nbackend\nbackends\nbackfill\nbackfilling\nbackfills\nbackticks\nBankless\nBanksy\nBarnabe\nBarnabé\nBarnabé's\nBastin\nBDN\nbeaconblock\nBeiko\nbenchmarking\nBertoni\nBesu\nBezout's\nBFT\nbidpool\nbigcup\nbilinear\nbilinearity\nBIP\nbitlist\nBitlists\nbitrate\nbitvector\nbitvector's\nbitvectors\nbitwise\nBLOBHASH\nblockchain\nblockchain's\nblockchains\nblockhash\nblockquote\nblockquotes\nblocksize\nbloXroute\nbloXroute's\nBLS\nbn\nBogotá\nboltdb\nBoneh\nbool\nbooleans\nbootnode\nbootnodes\nbootup\nborderless\nBPE\nBPO\nbroadcasted\nBSON\nbundlers\nButerin\nButerin's\nBylica\nbypassability\nbytecode\nbytecodes\nCalcDifficulty\nCalcExcessBlobGas\nCALLCODE\ncalldata\ncanonicalized\ncanonicalness\nCaplin\nCarb\ncartelization\nCasper\nCaversaccio\nCBOR\nCDAP\ncdot\ncdots\ncentralisation\ncentric\nCertora\nCEX\nchainId\nChallanges\nchangeset\nchangesets\nCharmes\nChaum\nchecksums\nChirag\ncli\nCLRS\ncmd\nCoC\nCodasip\ncodebase\ncodebases\ncodebreakers\ncodec\nCODECOPY\ncodecs\ncoinbase\ncollateralised\ncollateralized\nCOMIS\ncommoditized\nComposability\ncomposable\ncomputability\ncomputable\nconfig\ncongestions\nconnectionless\nConor\nConsensys\nCoq\nCorbellini\nCPUs\nCRS\nCrypto\ncryptocurrencies\ncryptocurrency\ncryptoeconomic\ncryptoeconomically\ncryptoeconomics\ncryptographic\ncryptographically\ncryptology\ncryptonative\nCryptopedia\ncryptopunks\ncryptosystem\ncryptosystems\nCSP\ncuration\ncustomizable\ncybersecurity\nCypherpunk\nCypherpunk's\nCypherpunks\nD'Amato\nDaemen\ndafny\nDai\nDankrad\ndanksharding\nDanno\nDany\nDAO\ndapp\nDapplion\ndapps\nDAS\nDatagram\ndataset\ndeboost\nDecaps\ndecrementation\ndecrementing\ndecrypted\ndecrypts\nDeFi\nDegatchi\nDELEGATECALL\ndelegator\ndelegators\ndeliverables\nDencun\ndeployer\ndescendent\ndeserialization\nDeserialize\ndeserialized\ndeserializer\nDesmos\ndev\nDevcon\ndevnet\ndevnets\nDevops\ndevp\nDevs\nDEX\nDHT\nDiffie\nDigiCash\ndigram\nDILITHIUM\nDimitar\ndisambiguated\nDiscordo\ndiscport\ndiscv\ndistro\nDNS\ndocsify\ndogecoin\nDomothy\ndotnet\nDownloader\nDracorn\nDragan\nDriscoll\nDSA\ndup\nDVT\ndx\nEAL\neas\nEB\nECADD\nECC\nECDH\nECDSA\nECDSA's\nECIES\nECMUL\nECPAIRING\nECRECOVER\necrerecover\nEdgington\nEdgington's\nEF\nefd\neg\neigenlayer\nEigenLayer's\nEIP\nEIPs\neK\nEL\nEL's\nElmore\nELs\nemptyset\nEncaps\nEncodings\nEndian\nenode\nENR\nenv\nEOA\nEOAs\nEOF\nEOF's\nEOY\neP\nePBS\nEPF\nEPFsg\nEphemery\nEPS\nepubs\nErb\nERC\nERCs\nErigon\nErigon's\nestimateGas\neth\netha\nEthash\nETHCC\nEthereum\nEthereum's\nEthereumJS\nEthernodes\nethers\nEthervm\nethone\nethone's\nEthPandaOps\nethresear\nethresearch\nethrex\nethroadmap\nethstaker\nETHW\nEVM\nEVM's\nevmlab\nEVMONE\nEVMs\nexcalidraw\nexchangeTransitionConfigurationV\nExplainer\nEXTCODESIZE\nExtractable\nextraData\nfanout\nfarcaster\nfastssz\nfaytey\nFCR\nFeamster\nFeist\nFemboy\nFerrin\nFFG\nFFT\nfilesystem\nfinalise\nfinancials\nFIPS\nFlashbot's\nFlashbots\nFlashboys\nFlashloans\nFN\nFOCIL\nforall\nForkchoice\nforkchoiceUpdatedV\nForky\nFormatting\nFORS\nFOSS\nfrac\nframeborder\nFrancesco\nFrege\nFriedrich\nfrontend\nfrontrunning\nfulfillments\nfullscreen\nFullstack\nFulu\nfunc\nfungibility\nFusaka\nfuzzer\nFuzzyVM\ngasless\nGasLimit\nGasper\ngasPrice\ngasUsed\nGCM\ngconnect\nGeorgios\ngeq\ngeth\nGeth's\ngetPayloadBodiesByHashV\ngetPayloadV\ngetters\nghost\nGilles\nGlaDOS\nGlamsterdam\nGoerli\nGolang\nGoldwasser\nGoomy\nGoron\nGorondan\ngossipsub\nGottfried\nGottlob\ngpg\nGPL\ngradle\ngradlew\nGrafana\nGrandine\nGrandine's\nGrigore\nGrup\nGuillaume\ngwei\nhackathon\nhackmd\nHager\nhalmos\nhardcoded\nhardfork\nHashedStorages\nHavel\nHerc's\nhevm\nHMAC\nhoc\nHOL\nHolesky\nhomomorphic\nHoodi\nHopinheimer\nhotfix\nHotz\nHsiao\nHSP\nHulsing\nHyperledger\nHyperplonk\nics\nIETF\niframe\nify\nImandra\nimg\nimpera\nimplementers\nincentivize\nincentivized\nincentivizes\nIncentivizing\nincludable\nincrementation\nincrementing\ninevitableeth\ninfrastracture\nInfura\ninit\ninitating\nInitcodeTransaction\ninitializationCode\nInsertCoin\ninstantiation\nintermediated\nintermediation\ninterop\ninterprocess\nintra\ninvariants\nIOP\nIPC\nIPFS\nIpsilon\nIPv\nIRTF\nISA\niteratively\nJitsi\njs\nJSON\nJUMPDEST\nJVM\nJWT\nkad\nKademlia\nKahn\nKanban\nKarapetsas\nKarim\nKatex\nKatya\nKDF\nKEC\nkeccak\nKeccak's\nkeecak\nKEM\nKEVM\nkeystore\nKira\nKira's\nKleppmann\nKoblitz\nKubernetes\nKurose\nKurtosis\nKyber\nKZG\nLamport\nLamport's\nLange\nlceil\nLDL\nldots\nlearnings\nLedgerwatch\nLeffew\nleftarrow\nLefteris\nleq\nleveldb\nlfloor\nLGPL\nlibmdbx\nlibp\nlifecycle\nLightclient\nLightclient's\nlinearizer\nlitecoin\nliveness\nLLM\nLLMs\nLMD\nlocktime\nLongrightarrow\nlookahead\nlookups\nloopback\nlor\nLSB\nLSM\nLSP\nLST\nLua\nLuaVM\nLuca\nLyubashevsky\nmainnet\nMana\nManas\nManu\nmathbb\nmaxEB\nMaximalism\nMayowa\nMDBX\nMDS\nmeldsun\nmem\nMempool\nmemtable\nmemtables\nMenezes\nmerkle\nMerkle's\nMerkleization\nMerkleize\nMerkleized\nMerkleizing\nMEV\nmevboost\nMichaël\nmiddleware\nMihai\nminimalistic\nmisconfigure\nMitigations\nmload\nMLWE\nMMPTs\nMODEXP\nmodularity\nmoduli\nMonnot\nmonorepo\nMonotonicity\nmortem\nMPC\nmplex\nMPT\nMSB\nMSIZE\nmstore\nMUL\nmultiaddr\nMultiaddress\nMultiaddrs\nmultibase\nMulticast\nMultihash\nmultihashes\nmultiproofs\nMurr\nMVE\nmvepbs\nMVI\nMário\nn't\nNagu\nNakamoto\nNalepa\nNamecoin\nnamespace\nnamespaces\nNand\nnatively\nneighbourhood\nneighbours\nneq\nNethermind\nNethermind's\nneuder\nnewPayloadV\nNFT\nNim\nNIST\nNIST's\nNixo\nNoam\nnonce\nnonces\nnonumber\nNOXX\nNSS\nNTRU\nNYU\nOcchipinti\nOdayan\nOFAC\nOffchain\noffsites\nommer\nommers\nonboarding\nonchain\nOOG\nOorschot\nopcode\nopcode's\nOpenRPC\nOpenZeppelin\noplus\nOQS\norderflows\norgs\nOSI\nOSI's\nParallelization\nParametrizing\nparams\nPari\nParithosh\nPawel\nPBS\nPectra\nPeerDAS\nPeeters\npepc\npepc's\nperformence\npermissionless\npermissionlessness\nPEX\nPGA\nPigovian\nPilipovic\npipelining\nPKCS\nPlaintext\nPlaydate\npmod\npng\nPOC\nPooja\nPOS\nPOSIX\npossibile\nPostel's\nPotuz\nPotuz's\nPOV\nPQ\nPQC\nPQCA\nPQS\nPR\nPR'ed\npre\npreAccesedStorageKeys\nprebuilt\nprecompile\nprecompiled\nprecompiles\npreconf\npreconfed\npreconfer\npreconfer's\npreconfers\npreconfirm\npreconfirmation\npreconfirmations\npreconfirmed\npreconfirms\npreconfs\npredeploy\nPreethi\npreimage\nPrest\nprev\nPREVRANDAO\nprivateKey\nprobabilistically\nprogrammability\nproto\nproto's\nprotobuf\nProtolambda\nprover\nProver's\nProvers\nPRs\nPrysm\nPrysm's\nPrysmatic\nPSE\nPSE's\npseudorandom\npseudorandomly\nptc\nptsd\npublically\npubsub\nPUSHX\npy\nPyrmont\nPyspec\npytest\nqquad\nqubits\nQUIC\nQuintus\nRaa\nRadicle\nradix\nrahul\nRahul's\nRANDAO\nRareskills\nRB\nrceil\nreachability\nREADME\nreciept\nreentrancy\nreferrerpolicy\nreimplementations\nremerkleable\nreorganisation\nreorganisations\nreplayable\nrepo\nReq\nResp\nresponder\nrestaking\nretesteth\nReth\nReth's\nreusability\nrevm\nrfloor\nrightarrow\nRikard\nRIPEMD\nRitchie\nRivest\nrK\nRLMD\nRLNC\nRLP\nRLPx\nroadmap\nRollCall\nrollup\nrollup's\nrollups\nROP\nRPC\nRPCs\nRSA\nRSA's\nruntime\nSatisfiability\nSatoshi\nSatoshi's\nscalability\nscalable\nschemas\nSchnorr\nSchocken\nSchwabe\nSECG\nsecp\nSELFDESTRUCT\nsemver\nSepolia\nserialize\nserializer\nSerokell\nsexualized\nSG\nSHA\nShacham\nshadowfork\nShafu\nShamir\nShapella\nSharded\nShardedKey\nsharding\nShareAlike\nShead\nShimon\nShisui\nShor\nShor's\nSiddharth\nsidechain\nSigP\nSilkwarm\nSilverman\nSipser\nslashable\nslashings\nSLH\nSLOAD\nsmlXL\nSMT\nSNARKify\nsocio\nsolvm\nSPHINCS\nSproul\nsrc\nSSD\nSSF\nSSLE\nSSTORE\nSSZ\nStackTooDeep\nstaker\nstakers\nStallman\nStateDB\nstateful\nstatelessness\nstateRoot\nSTATICCALL\nstf\nStorageShardedKey\nStoragesHistory\nStoragesTrie\nStreamEth\nsubcurrency\nsubnet\nsubnets\nsuboptimal\nSubprotocol\nsubprotocols\nsubstack\nSubstate\nsubtrees\nSumma\nSupermajority\nsurveilling\nsymlinks\nSynchronising\nsys\nsystemd\nSzabo\nTakenobu\nTaleb\nTalkReq\nTanenbaum\nTani\nTBD\ntbhl\nTCP\nTeku\ntestnet\ntestnets\nTetris\ntextnormal\ntexttt\ntimeframe\ntinygrad\nTLA\ntldr\nTLS\nTODO\ntoolchain\ntoolset\ntouchedAccounts\nTPS\ntracoor\ntradeoff\ntradeoffs\ntransactional\ntransactionId\ntrapdoored\ntrie\ntrie's\ntriggerable\ntrilemma\nTrin\nTrinfilesystem\ntrustless\ntrustlessly\ntrustlessness\nTrustLook\nTSTORE\nTTD\nTx\ntxcreate\ntxdatanonzero\ntxdatazero\ntxpool\ntxs\nUDP\nUI\nuint\nunaggregated\nunbundle\nUnbundling\nunderbrace\nunderflow\nunderflows\nunderpriced\nUnformatted\nunguessable\nunhandled\nunincentivized\nupstreamed\nutils\nuTP\nUTXO\nUTXOs\nUX\nVadim\nvalidator\nvalidator's\nvalidators\nVanstone\nVarun\nVasa\nVB's\nVDF\nVDFs\nVec\nverifications\nverifier\nverifiers\nVerkle\nverkled\nVictorio\nvirtualized\nvirtualizing\nVitalik\nVitalik's\nVM\nVyper\nwalkthrough\nWB\nwebkit\nWebRTC\nWetherall\nWhistleblower\nWhitepaper\nWHOAREYOU\nWinternitz\nWIP\nWireshark\nwithdrawable\nwithdrawalHash\nwordlist\nWOTS\nWSL\nWSS\nXatu\nxff\nXMSS\nXORed\nxy\nYAML\nyamux\nYan\nYellowpaper\nYoichi\nYoni\nZanolini\nZaryab\nZaverucha\nZhang\nZimmermann\nZipfian\nzk\nzkEVMs\nZKSNARK\nZKSNARKs\nZksync" } ]