diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml new file mode 100644 index 00000000000..ffdd250aa3d --- /dev/null +++ b/.github/workflows/build.yml @@ -0,0 +1,22 @@ +name: Build VitePress Site + +on: + push: + branches: [main] + pull_request: + +jobs: + build: + runs-on: ubuntu-latest + steps: + - name: Checkout + uses: actions/checkout@v4 + - name: Setup Node + uses: actions/setup-node@v4 + with: + node-version: 18 + cache: yarn + - name: Install dependencies + run: yarn install + - name: Build with VitePress + run: yarn build diff --git a/.vitepress/config.ts b/.vitepress/config.ts index 5eb08ecc6e4..a9116f11037 100644 --- a/.vitepress/config.ts +++ b/.vitepress/config.ts @@ -174,7 +174,7 @@ export default { { icon: "github", link: "https://github.com/celestiaorg/docs" }, { icon: "twitter", link: "https://twitter.com/CelestiaOrg" }, { icon: "youtube", link: "https://www.youtube.com/@CelestiaNetwork" }, - { icon: "discord", link: "https://discord.com/invite/YsnTPcSfWQ" }, + { icon: "discord", link: "https://discord.gg/celestiacommunity" }, { icon: { svg: telegramSVG }, link: "https://t.me/CelestiaCommunity" }, ], @@ -258,7 +258,7 @@ function nav() { { text: "Networks", link: "/nodes/participate" }, { text: "Nodes", link: "/nodes/overview" }, { text: "Developers", link: "/developers/build-whatever" }, - { text: "Community", link: "/community/overview" }, + { text: "Discord", link: "https://discord.gg/celestiacommunity" }, { text: "Quick start", items: [ @@ -338,6 +338,10 @@ function sidebarHome() { text: "Celestia glossary", link: "https://celestia.org/glossary/", }, + { + text: "Awesome Celestia resources", + link: "https://github.com/celestiaorg/awesome-celestia/", + }, ], }, ], @@ -471,7 +475,7 @@ function sidebarHome() { link: "/nodes/celestia-app-metrics", }, { - text: "Jailing and Slashing mechanics", + text: "Jailing and slashing mechanics", link: "/nodes/celestia-app-slashing", }, { @@ -501,7 +505,7 @@ function sidebarHome() { ], }, { text: "SystemD", link: "/nodes/systemd" }, - { text: "Hardfork process", link: "/nodes/hardfork-process" }, + { text: "Network upgrade process", link: "/nodes/network-upgrade-process" }, ], }, ], @@ -543,14 +547,6 @@ function sidebarHome() { text: "How to customize your Orbit chain's deployment configuration", link: "https://docs.arbitrum.io/launch-orbit-chain/how-tos/customize-deployment-configuration", }, - { - text: "Deploy a smart contract on Arbitrum rollup", - link: "/developers/arbitrum-smart-contract", - }, - { - text: "Deploy a dapp on your Arbitrum rollup devnet", - link: "/developers/arbitrum-dapp-deploy", - }, { text: "Audit", link: "https://github.com/celestiaorg/nitro/blob/celestia-v2.3.3/audits/celestia/arbitrum_nitro_celestia_audit_report.pdf", @@ -563,8 +559,8 @@ function sidebarHome() { items: [ { text: "Documentation", link: "https://docs.astria.org" }, { - text: "Deploy to Dusknet", - link: "https://docs.astria.org/docs/local-rollup/introduction/", + text: "Just deploy", + link: "https://docs.astria.org/developer/tutorials/install-the-cli", }, ], }, @@ -576,33 +572,27 @@ function sidebarHome() { text: "Intro to OP Stack integration", link: "/developers/intro-to-op-stack", }, - { - text: "Bubs testnet", - link: "/developers/bubs-testnet", - }, - { - text: "Raspberry testnet", - link: "https://raas.gelato.network/rollups/details/public/opcelestia-raspberry", - }, - { - text: "Deploy a smart contract on Bubs testnet", - link: "/developers/deploy-on-bubs", - }, - { - text: "Deploy a dapp on Bubs testnet", - link: "/developers/gm-portal-bubs", - }, { text: "Run an OP Stack devnet posting Celestia", link: "/developers/optimism", }, { - text: "Audit", - link: "https://docs.celestia.org/audits/Celestia_OP_Stack_Audit.pdf", + text: "OP Stack testnets", + collapsed: true, + items: [ + { + text: "Bubs testnet", + link: "/developers/bubs-testnet", + }, + { + text: "Raspberry testnet", + link: "https://raas.gelato.network/rollups/details/public/opcelestia-raspberry", + }, + ] }, { - text: "Deploy a dapp with thirdweb", - link: "https://thirdweb.com/bubs-testnet", + text: "Audit", + link: "https://docs.celestia.org/audits/Celestia_OP_Stack_Audit.pdf", }, { text: "Rollups as a Service", @@ -648,7 +638,7 @@ function sidebarHome() { items: [ { text: "Dymension", - link: "https://docs.dymension.xyz/build/overview/", + link: "https://docs.dymension.xyz/", }, ] } @@ -666,6 +656,10 @@ function sidebarHome() { text: "FeeGrant module for blobs submission", link: "/developers/feegrant-for-blobs", }, + { + text: "MultiAccounts feature for blobs submission", + link: "/developers/multiaccounts", + }, { text: "Transaction resubmission guidelines", link: "/developers/transaction-resubmission", @@ -717,45 +711,85 @@ function sidebarHome() { link: "/developers/blobstream-proof-queries", }, { - text: "Example implementation of Blobstream proofs by CryptoKass", - link: "https://github.com/CryptoKass/blobstreamx-example", - }, - { - text: "Local Blobstream X operators", + text: "SP1 Blobstream", collapsed: true, items: [ { - text: "Requesting data commitment ranges", - link: "/developers/blobstream-x-requesting-data-commitment-ranges", + text: "Local SP1 Blobstream operators", + collapsed: true, + items: [ + { + text: "New SP1 Blobstream deployments", + link: "/developers/sp1-blobstream-deploy", + }, + ], }, { - text: "New Blobstream X deployments", - link: "/developers/blobstream-x-deploy", + text: "SP1 Blobstream audits", + collapsed: true, + items: [ + { + text: "Ottersec", + link: "https://docs.celestia.org/audits/SP1_Blobstream_Ottersec_Audit.pdf", + }, + { + text: "SP1 Audits", + link: "https://github.com/succinctlabs/sp1/tree/dev/audits" + } + ] }, - ], + ] }, { - text: "Blobstream X audits", + text: "Blobstream X", collapsed: true, items: [ { - text: "Informal Systems", - link: "https://docs.celestia.org/audits/Blobstream_X-Informal_Systems_Audit.pdf", + text: "Overview of BlobstreamX", + link: "/developers/blobstreamx", }, { - text: "OtterSec", - link: "https://docs.celestia.org/audits/Blobstream_X-OtterSec_Audit.pdf", + text: "Example implementation of Blobstream proofs by CryptoKass", + link: "https://github.com/CryptoKass/blobstreamx-example", }, { - text: "Veridise", - link: "https://docs.celestia.org/audits/Blobstream_X-Veridise_Audit.pdf", + text: "Local Blobstream X operators", + collapsed: true, + items: [ + { + text: "Requesting data commitment ranges", + link: "/developers/blobstream-x-requesting-data-commitment-ranges", + }, + { + text: "New Blobstream X deployments", + link: "/developers/blobstream-x-deploy", + } + ] }, { - text: "Zellic", - link: "https://docs.celestia.org/audits/Blobstream_X-Zellic_Audit.pdf", + text: "Blobstream X audits", + collapsed: true, + items: [ + { + text: "Informal Systems", + link: "https://docs.celestia.org/audits/Blobstream_X-Informal_Systems_Audit.pdf", + }, + { + text: "OtterSec", + link: "https://docs.celestia.org/audits/Blobstream_X-OtterSec_Audit.pdf", + }, + { + text: "Veridise", + link: "https://docs.celestia.org/audits/Blobstream_X-Veridise_Audit.pdf", + }, + { + text: "Zellic", + link: "https://docs.celestia.org/audits/Blobstream_X-Zellic_Audit.pdf", + } + ], } - ], - } + ] + }, ], }, { @@ -779,12 +813,11 @@ function sidebarHome() { text: "Community", collapsed: true, items: [ - { text: "Overview", link: "/community/overview" }, + { text: "Discord", link: "https://discord.gg/celestiacommunity"}, { text: "Code of Conduct", link: "/community/coc" }, - { text: "Community calendar", link: "/community/calendar" }, - { text: "Celestia Foundation Delegation Program", - link: "/community/foundation-delegation-program" - }, + { text: "Celestia Foundation Delegation Program", + link: "/community/foundation-delegation-program" + }, { text: "Modular Meetups", collapsed: true, @@ -795,10 +828,6 @@ function sidebarHome() { { text: "Speaker list", link: "/community/speaker-list" }, ], }, - { - text: "Incentivized testnet supplemental terms", - link: "/community/itn-tos", - }, ], }, ]; diff --git a/.vitepress/constants/arabica_versions.js b/.vitepress/constants/arabica_versions.js index 120ef8839f8..c5f7523277d 100644 --- a/.vitepress/constants/arabica_versions.js +++ b/.vitepress/constants/arabica_versions.js @@ -1,9 +1,9 @@ const arabicaVersions = Object.freeze({ - "app-latest-tag": "v2.1.2", - "app-latest-sha": "48173df3dc78f9348eedb3796f29ef9e9e5dc584", + "app-latest-tag": "v2.2.0-arabica", + "app-latest-sha": "d3f8b2997fcbc8e7f43785a9513b2d0c91675087", "core-latest-tag": "v1.40.1-tm-v0.34.29-rc0", "core-latest-sha": "0d2b63836d0f4587e162bfded58f53fba238e69c", - "node-latest-tag": "v0.16.0-rc0", - "node-latest-sha": "603288597fbd82c44aaa0a0ac8d187cac1860431", + "node-latest-tag": "v0.18.1-arabica", + "node-latest-sha": "ac0515f82c2ae3783cfc62670dab3ad93cada8a6", }); export default arabicaVersions; diff --git a/.vitepress/constants/constants.js b/.vitepress/constants/constants.js index da9e713b30c..6bc81e6fe70 100644 --- a/.vitepress/constants/constants.js +++ b/.vitepress/constants/constants.js @@ -1,9 +1,9 @@ const constants = Object.freeze({ - golangNodeMainnet: "1.22.0", - golangNodeMocha: "1.22.0", - golangNodeArabica: "1.22.0", - golangApp: "1.22.0", - golangCore: "1.22.0", + golangNodeMainnet: "1.23.0", + golangNodeMocha: "1.23.0", + golangNodeArabica: "1.23.0", + golangApp: "1.22.6", + golangCore: "1.22.6", golang: "1.22.0", arabicaChainId: "arabica-11", mainnetChainId: "celestia", diff --git a/.vitepress/constants/mainnet_versions.js b/.vitepress/constants/mainnet_versions.js index a25eedd94b8..f322eb9497b 100644 --- a/.vitepress/constants/mainnet_versions.js +++ b/.vitepress/constants/mainnet_versions.js @@ -1,9 +1,9 @@ const mainnetVersions = Object.freeze({ - "app-latest-tag": "v1.13.0", - "app-latest-sha": "d40b04b5d38399daf1c7108c1ecc0de4603d4852", - "core-latest-tag": "v1.40.1-tm-v0.34.29-rc0", - "core-latest-sha": "0d2b63836d0f4587e162bfded58f53fba238e69c", - "node-latest-tag": "v0.15.0", - "node-latest-sha": "b745c60deff7d339c773d77e6b350a4a338ac682", + "app-latest-tag": "v2.1.2", + "app-latest-sha": "48173df3dc78f9348eedb3796f29ef9e9e5dc584", + "core-latest-tag": "v1.41.0-tm-v0.34.29", + "core-latest-sha": "aef322775c75783488b439cdf7ca33f38da08426", + "node-latest-tag": "v0.16.0", + "node-latest-sha": "6744f648649ebb5fee1b27faf7aca96ecf4519b2", }); export default mainnetVersions; diff --git a/.vitepress/constants/mocha_versions.js b/.vitepress/constants/mocha_versions.js index f9d44df5444..a0edc9eef7f 100644 --- a/.vitepress/constants/mocha_versions.js +++ b/.vitepress/constants/mocha_versions.js @@ -1,9 +1,9 @@ const mochaVersions = Object.freeze({ - "app-latest-tag": "v2.1.2", - "app-latest-sha": "48173df3dc78f9348eedb3796f29ef9e9e5dc584", + "app-latest-tag": "v2.2.0-mocha", + "app-latest-sha": "d3f8b2997fcbc8e7f43785a9513b2d0c91675087", "core-latest-tag": "v1.40.1-tm-v0.34.29-rc0", "core-latest-sha": "0d2b63836d0f4587e162bfded58f53fba238e69c", - "node-latest-tag": "v0.16.0-rc0", - "node-latest-sha": "603288597fbd82c44aaa0a0ac8d187cac1860431", + "node-latest-tag": "v0.18.2-mocha", + "node-latest-sha": "4309c8349857638b033a2a278da0f8ab182fdb26", }); export default mochaVersions; diff --git a/README.md b/README.md index cebca3c20f6..74b673d7894 100644 --- a/README.md +++ b/README.md @@ -1,6 +1,8 @@ +[![Deploy](https://github.com/celestiaorg/docs/actions/workflows/deploy.yml/badge.svg)](https://github.com/celestiaorg/docs/actions/workflows/deploy.yml) + # Celestia Documentation Site -Welcome to the official documentation repository for Celestia. +Welcome to the official documentation repository for [Celestia](https://celestia.org/). Here you'll find comprehensive guides, tutorials, and reference materials to help you make the most out of Celestia. @@ -20,7 +22,7 @@ This documentation site is built with [VitePress](https://vitepress.dev) We love contributions from the community! Whether you're fixing typos, improving content clarity, or adding new topics, every contribution helps. -- Fork & Clone: Fork this repository and clone it to your local machine. +- Fork & clone: Fork this repository and clone it to your local machine. - Branch: Always create a new branch for your changes. Naming it relevantly. - Commit Changes: Make your changes and commit them with a clear and concise commit message. diff --git a/community/calendar.md b/community/calendar.md deleted file mode 100644 index 0caed692ca6..00000000000 --- a/community/calendar.md +++ /dev/null @@ -1,14 +0,0 @@ ---- -description: Find all the different community call events happening in Celestia's community. ---- - -# Community calendar - -The Celestia community calendar is available for finding all the different -community call events happening in Celestia's community. - -[Add the community calendar to your personal calendar](https://calendar.google.com/calendar/u/0?cid=Y19za2JzbjIzNWszYmlzdHNoZ3RvNmw5ODYyNEBncm91cC5jYWxlbmRhci5nb29nbGUuY29t) -to stay updated with all the events. - -Explore [past community call agendas, notes, and recordings](https://github.com/celestiaorg/community-calls/blob/main/README.md) -for more insights. diff --git a/community/foundation-delegation-program.md b/community/foundation-delegation-program.md index 2d14de2e40c..b7afe157204 100644 --- a/community/foundation-delegation-program.md +++ b/community/foundation-delegation-program.md @@ -66,9 +66,9 @@ the delegation for the duration of the cohort they are currently in. The minimum requirements for participation in the program are as follows: -* Run an active mainnet validator **or** an active Mocha testnet validator +* Run an active Mainnet Beta validator **or** an active Mocha testnet validator for at least 1 month before application deadline -* Run a bridge node (on mainnet if you are already an active mainnet +* Run a bridge node (on Mainnet Beta if you are already an active Mainnet Beta validator or on Mocha testnet if not) that is connected and reporting to the Celestia Labs [OTEL collector](../nodes/celestia-node-metrics.md) (for new applicants - on testnet, so that we can evaluate performance) @@ -136,16 +136,16 @@ Before applying, be ready to share the following: * Website if any * Github page of your organization * Team experience and roster (including Twitter + Github links) - * Which networks you validate on mainnet + links to your validators + * Which networks you validate on Mainnet Beta + links to your validators * A personal statement why you should receive delegation from the Foundation (max 1500 characters) * Infrastructure - * Validator address and bridge node ID on MAINNET - * If you don't run an active mainnet validator, please provide us with + * Validator address and bridge node ID on Mainnet Beta + * If you don't run an active Mainnet Beta validator, please provide us with validator address, bridge node ID and blobstream address on Mocha-4 * Have you been slashed or jailed in the last 6 months on Celestia or other chains you validated on. - * Hosting provider and Data Center location (mainnet and testnet if applicable) + * Hosting provider and Data Center location (Mainnet Beta and testnet if applicable) * Setup of the 2 components (validator and bridge) * Hardware * Security setup (servers, private keys) diff --git a/community/itn-tos.md b/community/itn-tos.md deleted file mode 100644 index 5f03d084c1a..00000000000 --- a/community/itn-tos.md +++ /dev/null @@ -1,263 +0,0 @@ ---- -description: These Terms govern your ability to participate in the Incentivized Testnet Award Program. -lastUpdated: false -editLink: false ---- - -# SUPPLEMENTAL INCENTIVIZED TESTNET TERMS - - - - - - - -Last Revised on 1/16/2023 - -Welcome to the Supplemental Terms (these **"ITN Award Program Terms"** or **"Terms"**) -for the Incentivized Testnet Award Program -(the **"ITN Award Program"** or the **"Program"**) as operated on behalf of Strange -Loop Labs AG (**"Company"**, **"we"** or **"us"**). The ITN Award Program provides eligible -users of a Testnet designated by the Company the opportunity to earn rewards, -which may include Celestia tokens. These Terms are supplemental to, and -incorporate by reference, the broader Celestia Terms of Service -(**"Services Terms"**) available at [Celestia Terms of Service](https://celestia.org/tos). - -Defined terms used but not defined herein have the meaning set forth in the -Services Terms. The Program and your participation in it is a Service as -defined under the Services Terms. - -These Terms govern your ability to participate in the Program and any awards -you receive from that participation, which may include Celestia tokens (**"ITN Rewards"**). - -Please read these Terms carefully, as they include important information about -your legal rights. By participating in the Program or claiming ITN Rewards, -you are agreeing to these Terms. If you do not understand or agree to these -Terms, please do not participate in the Program or claim ITN Rewards. - -In order to participate in the Program you must provide certain information about you. -Our collection of such information, your rights with respect to such collection, -and other relevant information is described in the Celestia Privacy Policy available -at [Celestia Privacy Policy](https://celestia.org/privacy), and is supplemented by -Section 3 of these Terms. - -The Program is a discretionary Service provided by the Company, pursuant to which -the Company may, in its sole discretion, provide you ITN Rewards for your successful -completion of certain tasks on a Testnet designated by the Company. Please note that -any such Testnet itself (as well as any other Testnets or any mainnet deployment of -the Celestia Protocol) is not a Service and does not constitute an element of the -Services. We do not control the Celestia Protocol and accept no liability for its -operation or its deployment in any testnet or mainnet environment. - -## 1. General Terms - -**1.1** You must be eighteen (18) years of age or older and capable of forming a -binding contract with the Company in order to participate in the Program -or receive ITN Rewards. - -**1.2** You agree and acknowledge that you (a) may receive ITN Rewards for free -(other than applicable taxes, if any) from your participation in the Program, -(b) were not previously promised ITN Rewards, unless pursuant to a separate -written agreement, and (c) took no action in anticipation of or in reliance -on receiving any ITN Rewards, unless pursuant to a separate written agreement. - -**1.3** Your eligibility to participate in or receive ITN Rewards from the Program -is subject to our sole discretion. The complete list of actions you must complete -to earn ITN Rewards may not have been described in the documentation released by -us from time to time, you may not receive ITN Rewards even if you successfully -complete such actions, and no documentation related to the Program entitles you -to any ITN Rewards or to participate in the Program. - -**1.4** You agree and acknowledge that (a) you are not a Prohibited Person, (b) you -are not a U.S. Person as defined in Rule 902(k) of Regulation S under the U.S. -Securities Act of 1933, as amended (the **"1933 Act"** or **"Act"**), (c) you will not -use a VPN or other tool to circumvent any geoblock or other restrictions that -we may have implemented for participants in the Program, and (d) you are not -participating in, and have not become eligible to participate in, the Program -by receiving credentials from any other person or entity. Any circumvention or -violation of the above will permanently disqualify you from participation in the Program. - -**1.5** You agree and acknowledge that if you are unable to claim ITN Rewards due to -technical bugs, gas fees, loss of access to a Wallet or the keys thereto, or -for any other reason, you will have no recourse or claim against us or any other -Company Entity and that neither we nor any other Company Entity will bear any liability. - -**1.6** You agree and acknowledge that claiming an ITN Reward may require reliance -on or an integration with third party products (e.g., a Wallet or an unaffiliated -network or blockchain) that we do not control. In the event that you are unable to -access such products or integrations, or if they fail for any reason, and you are -unable to participate in the Program or claim ITN Rewards, you will have no recourse -or claim against us or any other Company Entity and neither we nor any other Company -Entity will bear any liability. - -**1.7** The Company may share identifying information and documentation with certain vendors -or third-party providers who provide such identity verification and sanctions and watchlist -screening services (the **"Third-Party Services"**). You agree that your access and use of -such Third-Party Services is governed solely by the terms and conditions of such Third-Party -Services, and the Company is not responsible or liable for, and make no representations -as to any aspect of such Third-Party Services, including, without limitation, their content -or the manner in which they handle, protect, manage or process data or any interaction -between you and the provider of such Third-Party Services. You irrevocably waive any claim -against the Company with respect to such Third-Party Services. We are not liable for any damage -or loss caused or alleged to be caused by or in connection with your enablement, access or -use of any such Third-Party Services, or your reliance on the privacy practices, data -security processes or other policies of such Third-Party Services. - -## 2. Taxes - -**2.1** You are responsible for the payment of all taxes associated with your participation in -the Program and your receipt of ITN Rewards. You agree to provide the Company with any -additional information and complete any required tax or other forms relating to your -receipt of ITN Rewards. You may suffer adverse tax consequences as a result of your -participation in the Program or your receipt of ITN Rewards. You hereby represent that -(a) you have consulted with a tax adviser that you deem advisable in connection with -your participation, or that you have had the opportunity to obtain tax advice but have -chosen not to do so, (b) the Company has not provided you with any tax advice with respect -to your participation, and (c) you are not relying on the Company for any tax advice. - -## 3. Supplemental Privacy Information - -We may collect information to help us determine the reliability or uptime of your activities -within the Program, including through the use of telemetry or metrics endpoints to collect -and analyse such information, and link this information to a unique identifier to represent -your activities within the Program. We may display all of the foregoing information on a -public dashboard. - -Additionally, we may collect certain information about you from Third-Party Services and -may combine information we receive from you with information we obtain from Third-Party -Services, including but not limited to: - -- Transaction information. Information related to transactions in your Wallet, your Wallet - address, activities performed using your Wallet, tokens received by your Wallet, or - transactions initiated or completed. -- Identification information. We collect your government identification (e.g., driver’s - license, passport, etc.), proof of address, biometric information, and entity formation - information if applicable. By agreeing to these Terms, you consent to our use of your - biometric information, and understand and agree that our use of the biometric information - is necessary for the performance of these Terms and the implementation of the Services. - -We collect this information to confirm your eligibility to participate in the Program and receive -ITN Rewards, comply with our legal obligations, detect and prevent fraud, and to -provide you with the Program. - -Any information we receive from third-party sources will be treated in accordance with the -Celestia Privacy Policy, available at [Celestia Privacy Policy](https://celestia.org/privacy). -We are not responsible or liable for the accuracy of the information provided to us by third parties -and are not responsible for any third party’s policies or practices. See Section 9 of the Celestia -Privacy Policy for more information. - -## 4. Certain Additional Representations - -**4.1** Receipt of Rewards Entirely for Own Account. Your eligibility to receive ITN Rewards is made -in reliance upon your representation to the Company, which by your agreement to these Terms you -hereby confirm, that any ITN Rewards you receive will be for your own account, not as a nominee -or agent, and not with a view to the resale or distribution of any part thereof, and that you have -no present intention of selling, granting any participation in, or otherwise distributing the same. -By agreeing to these Terms, you further represent that you do not presently have any contract, -undertaking, agreement or arrangement with any person to sell, transfer or grant participations -to such person or to any third person, with respect to any ITN Rewards. If you are agreeing to -these terms on behalf of an entity, that entity has not been formed for the specific purpose of -obtaining the ITN Rewards. - -**4.2** Disclosure of Information. Your eligibility to receive ITN Rewards is made in reliance upon your -representation to the Company, which by your agreement to these Terms you hereby confirm, that you -have sufficient knowledge of and experience in business and financial matters to be able to evaluate -the risks and merits of your participation in the Program and of any ITN Rewards and are able to bear -the risks thereof. You hereby affirm that you have not relied on any representations or warranties -made by the Company related to the Program, including, but not limited to, conversations of any kind, -whether through oral or electronic communication, or any white paper. - -**4.3** Compliance with United States Securities Laws. You understand that the ITN Rewards -have not been, and will not be, registered under the 1933 Act or any applicable state -securities laws. You acknowledge that the availability of an exemption from the registration -provisions of the Securities Act and other applicable state securities laws depends upon, -among other things, the bona fide nature of your intent as described in Section 4.1 above -and with respect to the accuracy of your representations as expressed throughout these Terms. -You understand that the ITN Rewards may be deemed "restricted securities" under applicable -United States federal and state securities laws and that, pursuant to these laws, you may be -restricted from transferring any ITN Rewards unless they are registered with the Securities -and Exchange Commission and qualified by state authorities, or an exemption from such registration -and qualification requirements is available. You acknowledge that the Company does not undertake -any obligation to register or qualify the ITN Rewards for resale, and exemptions from registration -and qualification may not be available or may not permit you to transfer all or any of the ITN Rewards -in the amounts or at the times proposed by you. You further acknowledge that if an -exemption from registration or qualification is available, such exemption may be -conditioned on various requirements including, but not limited to, the time and manner -of sale, the holding period for the ITN Rewards, and on other factors outside of your -control, for which the Company makes no assurances and may not be able to satisfy. - -**4.4** Compliance with Liechtenstein Security Law. You understand that nothing in these -Terms will be deemed to constitute a prospectus of any sort in Liechtenstein or in -any jurisdiction in the EU; nor does it in any way pertain to a public offering or -a solicitation of an offer to buy any securities in Liechtenstein or in any -jurisdiction in the EU. - -**4.5** No Public Market. You understand that no public market now exists for the -ITN Rewards, and that the Company has not made any assurances that a public -market will ever exist for the ITN Rewards. - -**4.6** No Solicitation. At no time were you presented with or solicited by any publicly -issued or circulated newspaper, mail, radio, television or other form of general -advertising or solicitation in connection with any invitation to participate in -the Program or offer of the ITN Rewards. - -**4.7** Other Applicable Laws. You hereby represent that you have satisfied yourself -as to the full observance of the laws of your jurisdiction in connection with -any invitation to participate in the Program, receipt of ITN Awards, and other -use of these Terms, including (a) the legal requirements within your jurisdiction -for participating in the Program and receiving ITN Rewards, (b) any foreign exchange -restrictions applicable to such participation or receipt, (c) any governmental or -other consents that may need to be obtained, and (d) the income tax and other tax -consequences, if any, that may be relevant to the receipt, holding, sale, or transfer -of the ITN Rewards. Your participation in the Program and continued beneficial -ownership of ITN Rewards will not violate any applicable securities or other -laws of your jurisdiction. - -**4.8** Non-US Transaction. You are not a U.S. Person as defined in Rule 902(k) -of Regulation S under the 1933 Act. The offer of the ITN Rewards to you was -made in an offshore transaction (as defined in Rule 902(h) of Regulation S), -no directed selling efforts (as defined in Rule 902(c) of Regulation S) were -made in the United States, and you are not obtaining the ITN Rewards for the -account or benefit of any U.S. Person. - -**4.9** Transfer Restrictions. You will not, during the Restricted Period -(as defined below) offer or sell any of the ITN Rewards (or create or maintain -any derivative position equivalent thereto) in the United States, to or for -the account or benefit of a U.S. Person or other than in accordance with -Regulation S. The Company reserves the right to impose additional transfer -restrictions with respect to the ITN Rewards in its sole discretion. - -**4.10** Subsequent Sales. You will, after the expiration of the applicable -Restricted Period, only offer, sell, pledge or otherwise transfer the ITN Rewards -(or create or maintain any derivative position equivalent thereto) pursuant to -registration under the 1933 Act or any available exemption therefrom and, -in any case, in accordance with applicable state securities laws. - -**4.11** Legends. You acknowledge and agree that the ITN Rewards will be deemed -to bear the following legends: (a) any legend required by the securities -laws of any state or country to the extent such laws are applicable to the -ITN Rewards represented by the certificate so legended, and (b): the following -legend (and even without such legend the following restrictions apply): - -THE ITN REWARDS HAVE NOT BEEN REGISTERED UNDER THE ACT WITH THE UNITED STATES -SECURITIES AND EXCHANGE COMMISSION, AND THE COMPANY DOES NOT INTEND TO REGISTER THEM. -THE ITN REWARDS HAVE BEEN OBTAINED TO HOLD FOR THE LONG TERM AND NOT WITH A VIEW TO, -OR IN CONNECTION WITH, THE SALE OR DISTRIBUTION THEREFOR. PRIOR TO THE ONE YEAR -ANNIVERSARY FROM THE TERMINATION OF THE ITN REWARD PROGRAM (THE **"PROGRAM COMPLETION -DATE"** AND SUCH ONE YEAR PERIOD, THE **"RESTRICTED PERIOD"**), THE ITN REWARDS MAY NOT BE -OFFERED OR SOLD (INCLUDING OPENING A SHORT POSITION IN SUCH ITN REWARDS) IN THE -UNITED STATES OR TO U.S. PERSONS AS DEFINED BY RULE 902(k) ADOPTED UNDER THE ACT, -OTHER THAN TO DISTRIBUTORS, UNLESS THE ITN REWARDS ARE REGISTERED UNDER THE ACT, -OR AN EXEMPTION FROM THE REGISTRATION REQUIREMENTS OF THE ACT IS AVAILABLE. -RECIPIENTS OF ITN REWARDS PRIOR TO THE ONE YEAR ANNIVERSARY OF THE PROGRAM -COMPLETION DATE MAY SELL SUCH ITN REWARDS ONLY PURSUANT TO AN EXEMPTION FROM -REGISTRATION UNDER THE ACT OR OTHERWISE IN ACCORDANCE WITH THE PROVISIONS OF -REGULATION S OF THE ACT, OR IN TRANSACTIONS EFFECTED OUTSIDE OF THE UNITED STATES -PROVIDED THEY DO NOT SOLICIT (AND NO ONE ACTING ON THEIR BEHALF SOLICITS) PURCHASERS -IN THE UNITED STATES OR OTHERWISE ENGAGE(S) IN SELLING EFFORTS IN THE UNITED STATES -AND PROVIDED THAT HEDGING TRANSACTIONS INVOLVING THESE ITN REWARDS MAY NOT BE CONDUCTED -UNLESS IN COMPLIANCE WITH THE ACT. A HOLDER OF THE ITN REWARDS WHO IS A DISTRIBUTOR, -DEALER, SUB-UNDERWRITER OR OTHER SECURITIES PROFESSIONAL, IN ADDITION, CANNOT PRIOR -TO THE ONE YEAR ANNIVERSARY OF THE PROGRAM COMPLETION DATE SELL THE ITN REWARDS TO -A U.S. PERSON AS DEFINED BY RULE 902(k) OF REGULATION S UNLESS THE ITN REWARDS ARE -REGISTERED UNDER THE ACT OR AN EXEMPTION FROM REGISTRATION UNDER THE ACT IS AVAILABLE. diff --git a/community/overview.md b/community/overview.md deleted file mode 100644 index 00d25cb61fa..00000000000 --- a/community/overview.md +++ /dev/null @@ -1,8 +0,0 @@ -# Community overview - -This section will highlight all the different resources and activities -for the Celestia community. - -Here you will find links to our [community calendar](./calendar.md), -[Code of Conduct](./coc.md) -and other community-related resources. diff --git a/developers/arbitrum-bridge.md b/developers/arbitrum-bridge.md index 0da3f3da6a3..bb7ffde6687 100644 --- a/developers/arbitrum-bridge.md +++ b/developers/arbitrum-bridge.md @@ -1,5 +1,8 @@ --- description: A guide on how to bridge in and out of your Arbitrum Orbit rollup. +next: + text: "Intro to OP Stack integration" + link: "/developers/intro-to-op-stack" --- # Bridging in and out of your Orbit rollup diff --git a/developers/arbitrum-dapp-deploy.md b/developers/arbitrum-dapp-deploy.md deleted file mode 100644 index 4e5bbe21f2e..00000000000 --- a/developers/arbitrum-dapp-deploy.md +++ /dev/null @@ -1,120 +0,0 @@ ---- -description: Make your own GM Portal dapp on your Arbitrum rollup. -next: - text: "Intro to OP Stack integration" - link: "/developers/intro-to-op-stack" ---- - -# Deploy a dapp on your Arbitrum rollup devnet - -First, review the [Arbitrum integration](./arbitrum-integration.md), -[Quickstart: Deploy an Arbitrum Orbit rollup](./arbitrum-deploy.md), and -[Deploy a smart contract to your Arbitrum rollup](./arbitrum-smart-contract.md) -pages. - -## Dependencies - -- a funded account to deploy your smart contract -- an [Arbitrum rollup devnet](./arbitrum-deploy.md) running - -## Setup and contract deployment - -1. Clone the `gm-portal` from GitHub and start the frontend: - - ```bash - cd $HOME - git clone https://github.com/jcstein/gm-portal.git - cd gm-portal && git checkout arbitrum - cd frontend && yarn && yarn dev - ``` - -2. In a new terminal instance, set your private key for the - faucet as a variable and the RPC URL you're using: - - ```bash - export PRIVATE_KEY=0xb6b15c8cb491557369f3c7d2c287b053eb229daa9c22138887752191c9520659 - export ARB_RPC_URL=http://localhost:8547 - ``` - -3. Change into the `gm-portal/contracts` directory in the same terminal and deploy - the contract using Foundry: - - - - ```bash - cd $HOME/gm-portal/contracts - forge script script/GmPortal.s.sol:GmPortalScript --rpc-url $ARB_RPC_URL --private-key $PRIVATE_KEY --broadcast - ``` - - - -4. In the output of the deployment, find the contract address and set it as a variable: - - ```bash - export CONTRACT_ADDRESS= - ``` - -### Interact with the contract - -Next, you're ready to interact with the contract from your terminal! - -1. Send a "gm" to the contract: - - ```bash - cast send $CONTRACT_ADDRESS \ - "gm(string)" "gm" \ - --private-key $PRIVATE_KEY \ - --rpc-url $ARB_RPC_URL - ``` - -2. Now that you've posted to the contract, you can read all "gms" (GMs) from the - contract with - this command: - - ```bash - cast call $CONTRACT_ADDRESS "getAllGms()" --rpc-url $ARB_RPC_URL - ``` - -3. Next, query the total number of gms, which will be returned as a hex value: - - ```bash - cast call $CONTRACT_ADDRESS "getTotalGms()" --rpc-url $ARB_RPC_URL - ``` - -4. (Optional) In order to interact with the contract on the frontend, you'll - need to fund an account that you have in your Ethereum wallet. Transfer to an - external account with this command: - - ```bash - export RECEIVER= - cast send --private-key $PRIVATE_KEY $RECEIVER --value 1ether --rpc-url $ARB_RPC_URL - ``` - - :::tip - If you are in a different terminal than the one you set the - private key in, you may need to set it again. - ::: - -## Update the frontend - -Next, you will need to update a few things before you can interact with the -contract on the frontend: - -1. Change the contract address on `gm-portal/frontend/src/App.tsx` to your - contract address -2. Match the chain info on `gm-portal/frontend/src/main.tsx` with the chain - config of your L2 -3. If you changed the contract, update the ABI in - `gm-portal/frontend/GmPortal.json` from - `gm-portal/contracts/out/GmPortal.sol/GmPortal.json`. This can be done with: - -```bash -cd $HOME -cp dev/gm-portal/contracts/out/GmPortal.sol/GmPortal.json dev/gm-portal/frontend -``` - -## Interact with the frontend - -Now, login with your wallet that you funded, and post a GM on your GM portal! - -![gm-arb](/img/gm-arb.png) diff --git a/developers/arbitrum-deploy.md b/developers/arbitrum-deploy.md index 088772f4f76..b331a49e3cd 100644 --- a/developers/arbitrum-deploy.md +++ b/developers/arbitrum-deploy.md @@ -123,7 +123,7 @@ deploy your Orbit chain. After configuring your batch poster, proceed to the next step. -### Step 3: Review & Deploy your Orbit chain +### Step 4: Review & Deploy your Orbit chain Now, deploy your chain's base contracts to Arbitrum Sepolia! @@ -154,7 +154,7 @@ the challenge mechanism, bridging mechanisms, and more. Once your transaction is complete, continue to Step 4 to download your chain's configuration files and launch your chain. -### Step 4: Download your chain's configuration files and launch your chain +### Step 5: Download your chain's configuration files and launch your chain After configuring your chain, you will need to download the necessary configuration files to launch your chain. Click the **Download zip files** button to download both the Rollup Config and L3 Config in a single ZIP file. @@ -166,7 +166,7 @@ Ensure to securely store these downloaded files as they contain sensitive inform ![download config](/arbitrum/download-config.png) -### Step 5: Clone the setup script repository and add your configuration files +### Step 6: Clone the setup script repository and add your configuration files 1. Clone the [orbit-setup-script](https://github.com/celestiaorg/orbit-setup-script/tree/main) repository: @@ -181,7 +181,7 @@ root of your cloned `orbit-setup-script` repository. 3. Install dependencies by running `yarn install` from the root of the `orbit-setup-script` repository. -### Step 6: Pick an L2 RPC URL for the Batch Poster +### Step 7: Pick an L2 RPC URL for the Batch Poster In order for the Batch Poster, which is responsible for posting batches of data, to subscribe to Blobstream's smart contract events, the node most use a WebSocket @@ -210,7 +210,7 @@ and successfully subscribe to Blobstream events. Without a WSS connection, the Batch Poster won't be able to subscribe to Blobstream events, and thus will fall back to posting data to parent chain. -### Step 7: Run your light node for Mocha testnet +### Step 8: Run your light node for Mocha testnet First, be sure that your light node is running, using a command similar to: @@ -297,7 +297,7 @@ This is crucial to protect against potential misuse by copy-paste errors. [See the compatibility matrix in the appendix to verify you're using the right versions.](#compatibility-matrix) -### Step 8: Run your chain's node and block explorer +### Step 9: Run your chain's node and block explorer Start Docker, then run `docker-compose up -d` from the root of the `orbit-setup-script` repository. @@ -313,7 +313,7 @@ After you have some activity on your rollup, it will look more like this: ![explorer-view](/arbitrum/explorer-view.png) -### Step 9: Finish setting up your chain +### Step 10: Finish setting up your chain The Offchain Labs team has provided a Hardhat script that handles the following tasks: diff --git a/developers/arbitrum-smart-contract.md b/developers/arbitrum-smart-contract.md deleted file mode 100644 index 64257114aa6..00000000000 --- a/developers/arbitrum-smart-contract.md +++ /dev/null @@ -1,270 +0,0 @@ ---- -description: A tutorial that guides you through the process of deploying a smart contract to your Arbitrum rollup using a L2 Nitro devnet, including setting up the environment, creating and testing the smart contract, and interacting with the deployed contract. ---- - -# Deploy a smart contract to your Arbitrum rollup - -## Overview - -Welcome to the guide on deploying a smart contract to your Arbitrum rollup. In -this tutorial, you will learn how to deploy a smart contract using the L2 Nitro -devnet and the provided public and private keys for testing purposes. - -## Prerequisites - -- [Nitro rollup devnet](./arbitrum-deploy.md) - running -- [Foundry](https://getfoundry.sh/) installed on your machine -- [Node.js](https://nodejs.org/en) -- Basic understanding of Ethereum -- Basic understanding of Solidity and Node.js - -## Setup - -First, in your `$HOME` directory, set up a new project folder for this -tutorial and init the project with npm: - -```bash -cd $HOME -mkdir counter-project && cd counter-project && npm init -y -``` - -Next, initialize a Foundry project with the following command: - -```bash -forge init counter_contract -``` - -## Create your smart contract - -Take a look at the `Counter.sol` file in your -`counter-project/counter_contract/src` directory: - -```solidity -// SPDX-License-Identifier: UNLICENSED -pragma solidity ^0.8.13; - -contract Counter { - uint256 public number; - - function setNumber(uint256 newNumber) public { - number = newNumber; - } - - function increment() public { - number++; - } -} -``` - -The contract contains a public unsigned integer variable named "number". -There are two public functions in this contract. The `setNumber` function -allows anyone to set a new value for the "number" variable, while the -`increment` function increases the value of "number" by one each time it's -called. - -You can -[learn more about Solidity and smart contract programming](https://ethereum.org/en/developers/learning-tools/). - -To compile the contract, run the following forge command from the -`$HOME/counter-project/counter_contract/` directory: - -```bash -forge build -``` - -Your output should look similar to the following: - -```bash -[⠢] Compiling... -[⠔] Compiling 21 files with 0.8.19 -[⠑] Solc 0.8.19 finished in 1.24s -Compiler run successful -``` - -## Test your smart contract - -Now, open the `test/Counter.t.sol` file: - -```solidity -// SPDX-License-Identifier: UNLICENSED -pragma solidity ^0.8.13; - -import "forge-std/Test.sol"; -import "../src/Counter.sol"; - -contract CounterTest is Test { - Counter public counter; - - function setUp() public { - counter = new Counter(); - counter.setNumber(0); - } - - function testIncrement() public { - counter.increment(); - assertEq(counter.number(), 1); - } - - function testSetNumber(uint256 x) public { - counter.setNumber(x); - assertEq(counter.number(), x); - } -} -``` - -This file performs unit testing on the contract we created in the previous -section. Here's what the test is doing: - -- The contract includes a public "Counter" type variable called "counter". - In the `setUp` function, it initializes a new instance of the "Counter" - contract and sets the "number" variable to 0. - -- There are two test functions in the contract: `testIncrement` and - `testSetNumber`. - -- The `testIncrement` function tests the "increment" function of the - "Counter" contract by calling it and then asserting that the "number" in - the "Counter" contract is 1. It verifies if the increment operation - correctly increases the number by one. - -- The `testSetNumber` function is more generic. It takes an unsigned integer - argument 'x' and tests the "setNumber" function of the "Counter" contract. - After calling the "setNumber" function with 'x', it asserts that the - "number" in the "Counter" contract is equal to 'x'. This verifies that the - "setNumber" function correctly updates the "number" in the "Counter" - contract. - -Now, to test your code, run the following: - -```bash -forge test -``` - -If the test is successful, your output should be similar to this: - -```bash -[⠆] Compiling... -No files changed, compilation skipped - -Running 2 tests for test/Counter.t.sol:CounterTest -[PASS] testIncrement() (gas: 28334) -[PASS] testSetNumber(uint256) (runs: 256, μ: 27709, ~: 28409) -Test result: ok. 2 passed; 0 failed; finished in 8.96ms -``` - -## Deploying your smart contract - -### Funded accounts - -Your L2 Nitro devnet will have a -[public and private key funded as a faucet to use for testing](https://docs.arbitrum.io/node-running/how-tos/local-dev-node#default-endpoints-and-addresses): - -- On both L1 and L2 - - Public key: `0x3f1Eae7D46d88F08fc2F8ed27FCb2AB183EB2d0E` - - Private key: - `0xb6b15c8cb491557369f3c7d2c287b053eb229daa9c22138887752191c9520659` - -Alternatively, you can -[fund other addresses by using the scripts `send-l1` and `send-l2`](https://docs.arbitrum.io/node-running/how-tos/local-dev-node#helper-scripts). - -The L1 Geth devnet will be running at `http://localhost:8545` and the L2 Nitro -devnet will be on `http://localhost:8547` and `ws://localhost:8548`. - -### Using our Arbitrum devnet - -We will use the local RPC endpoint (`http://localhost:8547`) and accounts -above to test with. - -Let's deploy the contract now. First, set a private key from anvil: - -```bash -export L2_PRIVATE_KEY=0xe887f7d17d07cc7b8004053fb8826f6657084e88904bb61590e498ca04704cf2 -export ARB_RPC_URL=http://localhost:8547 -``` - -Now, deploy the contract: - -```bash -forge create --rpc-url $ARB_RPC_URL \ - --private-key $L2_PRIVATE_KEY \ - src/Counter.sol:Counter -``` - -A successful deployment will return output similar to below: - -```bash -[⠆] Compiling... -No files changed, compilation skipped -Deployer: 0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266 -Deployed to: 0x5FbDB2315678afecb367f032d93F642f64180aa3 -Transaction hash: 0xf1a793a793cd9fc588f5132d99008565ea361eb3535d66499575e9e1908200b2 -``` - -Once you've deployed the contract, you're ready to interact with it! - -First, we'll set it as a variable: - -```bash -export CONTRACT_ADDRESS=0x5FbDB2315678afecb367f032d93F642f64180aa3 -``` - -## Interacting with your smart contract - -Foundry uses `cast`, a CLI for performing Ethereum RPC calls. - -To write to the contract, we'll use the `cast send` command: - - - -```bash -cast send $CONTRACT_ADDRESS "setNumber(uint256)" 10 \ - --rpc-url $ARB_RPC_URL --private-key $L2_PRIVATE_KEY -``` - -Your output will look similar: - -```bash -blockHash 0x131822bef6eb59656d7e1387c19b75be667e587006710365ec5cf58030786c42 -blockNumber 3 -contractAddress -cumulativeGasUsed 43494 -effectiveGasPrice 3767182372 -gasUsed 43494 -logs [] -logsBloom 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 -root -status 1 -transactionHash 0x8f15d6004598f0662dd673a9898dceef77be8cc28408cecc284b28d7be32307d -transactionIndex 0 -type 2 -``` - - - -Now, we can make a read call to view the state of the number variable, -using the `cast call` command: - -```bash -cast call $CONTRACT_ADDRESS "number()" --rpc-url $ARB_RPC_URL -``` - -The result will look similar: - -```bash -0x000000000000000000000000000000000000000000000000000000000000000a -``` - -Convert the result from hexadecimal to a base 10 value with: - -```bash -echo $((0x000000000000000000000000000000000000000000000000000000000000000a)) -``` - -## Next steps - -Congratulations! You've learned how to deploy a smart contract to your Arbitrum -rollup devnet. - -What will you build next? In our next tutorial, we will be going over how to -deploy a dapp to your Arbitrum rollup. diff --git a/developers/blobstream-contracts.md b/developers/blobstream-contracts.md index 4c5efc3438e..0352b54990b 100644 --- a/developers/blobstream-contracts.md +++ b/developers/blobstream-contracts.md @@ -1,6 +1,9 @@ --- sidebar_label: Integrate with Blobstream contracts description: Learn how to integrate your L2's onchain logic with Blobstream +prev: + text: "Overview of Blobstream" + link: "/developers/blobstream" --- # Integrate with Blobstream contracts @@ -13,15 +16,14 @@ Make sure to have the following installed: - [Foundry](https://github.com/foundry-rs/foundry) -### Installing Blobstream X contracts +### Installing Blobstream contracts -We will be using the Blobstream X implementation of -Blobstream, so we can install its repo as a dependency: - -Install the Blobstream X contracts repo as a dependency: +We will be using the [`IDAOracle`](https://github.com/celestiaorg/blobstream-contracts/blob/master/src/IDAOracle.sol) +interface to verify inclusion. +So, we will install the Blobstream contracts repo as a dependency: ```sh -forge install succinctlabs/blobstreamx --no-commit +forge install celestiaorg/blobstream-contracts --no-commit ``` Make sure that the directory you're running this command @@ -44,30 +46,29 @@ Example minimal Solidity contract for a stub ZK rollup that leverages the // SPDX-License-Identifier: Apache-2.0 pragma solidity ^0.8.19; -TBD import "blobstream-contracts/IDAOracle.sol"; import "blobstream-contracts/DataRootTuple.sol"; import "blobstream-contracts/lib/tree/binary/BinaryMerkleProof.sol"; contract MyRollup { - IDAOracle immutable blobstreamX; + IDAOracle immutable blobstream; bytes32[] public rollup_block_hashes; - constructor(IDAOracle _blobstreamX) { - blobstreamX = _blobstreamX; + constructor(IDAOracle _blobstream) { + blobstream = _blobstream; } function submitRollupBlock( bytes32 _rollup_block_hash, bytes calldata _zk_proof, - uint256 _blobstreamX_nonce, + uint256 _blobstream_nonce, DataRootTuple calldata _tuple, BinaryMerkleProof calldata _proof ) public { // Verify that the data root tuple (analog. block header) has been // attested to by the Blobstream contract. require( - blobstreamX.verifyAttestation(_blobstreamX_nonce, _tuple, _proof) + blobstream.verifyAttestation(_blobstream_nonce, _tuple, _proof) ); // Verify the ZKP (zero-knowledge proof). diff --git a/developers/blobstream-offchain.md b/developers/blobstream-offchain.md index 07652ad0962..35acd0ea87d 100644 --- a/developers/blobstream-offchain.md +++ b/developers/blobstream-offchain.md @@ -10,7 +10,7 @@ Rollups can use Blobstream for DA by posting their data to Celestia and then proving that it was posted on Ethereum. This is done identically to how any rollup or user would post data to Celestia. Then, a zero-knowledge proof that Celestia validators have come to consensus on Celestia block headers is -generated, and subsequently relayed to Ethereum to the Blobstream X smart +generated, and subsequently relayed to Ethereum to the Blobstream smart contract. This demo rollup will outline (the outline is not an diff --git a/developers/blobstream-proof-queries.md b/developers/blobstream-proof-queries.md index c5724a92df0..ab4914ad56b 100644 --- a/developers/blobstream-proof-queries.md +++ b/developers/blobstream-proof-queries.md @@ -1,8 +1,5 @@ --- description: Learn how to query the inclusion proofs used in Blobstream -next: - text: "Requesting data commitment ranges" - link: "/developers/requesting-data-commitment-ranges" --- # Blobstream proofs queries @@ -35,14 +32,27 @@ used for the queries. It can be initialized using: }(trpc) ``` -The `` can be retrieved from [mainnet](../nodes/mainnet.md) for -Celestia mainnet beta, and [mocha](../nodes/mocha-testnet.md) for the Mocha testnet. +The `` can be retrieved from [Mainnet Beta](../nodes/mainnet.md#integrations) for +and [Mocha](../nodes/mocha-testnet.md) for the Mocha testnet. In case the reader wants to interact with an on-chain contract that can be used to verify that data was posted to Celestia, the bindings of that contract are needed. -For Blobstream, the golang bindings can be found in the [Blobstream X](https://github.com/succinctlabs/blobstreamx/blob/main/bindings/BlobstreamX.go) -repository. For other languages, the corresponding smart contract bindings should +For Blobstream, the golang bindings can be found in the following links: + +::: code-group + +```text [BlobstreamX] +https://github.com/succinctlabs/blobstreamx/blob/main/bindings/BlobstreamX.go +``` + +```text [SP1 Blobstream] +https://github.com/succinctlabs/sp1-blobstream/blob/main/bindings/SP1Blobstream.go +``` + +::: + +For other languages, the corresponding smart contract bindings should be generated. Refer to [abigen](https://geth.ethereum.org/docs/tools/abigen) for more information. @@ -79,10 +89,8 @@ portion of the specs. ![Blobstream Commitment Diagram](/img/blobstream/blobstream-commitment-diagram.png) So to prove inclusion of a share to a Celestia block, we use Blobstream -as a source of truth. Currently, we will be using the Blobstream X implementation -of Blobstream, more information on Blobstream X can be found in -[the overview](./blobstream.md#blobstream-x). In a nutshell, Blobstream X -attests to the data posted to Celestia in the Blobstream X contract via +as a source of truth. In a nutshell, Blobstream +attests to the data posted to Celestia in the zk-Blobstream contract via verifying a zk-proof of the headers of a batch of Celestia blocks. Then, it keeps reference of that batch of blocks using the merkleized commitment of their `(dataRoot, height)` resulting in a `data root tuple root`. @@ -102,12 +110,17 @@ Check the above diagram which shows: - 3: in order to batch multiple blocks into the same commitment, we create a commitment over the `(dataRoot, height)` tuple for a batch of blocks, which results in a data root tuple root. It's this commitment that gets - stored in the Blobstream X smart contract. + stored in the Blobstream smart contract. + +So, if we're able to prove: -So, if we're able to prove that a share is part of a row, then that row is -committed to by a data root. Then, prove that that data root along with its +- That a share is part of a row, then that row is +committed to by a data root. +- Then, prove that that data root along with its height is committed to by the data root tuple root, which gets saved to the -Blobstream X contract, we can be sure that that share was committed to in +Blobstream contract. + +We can be sure that that share was committed to in the corresponding Celestia block. In this document, we will provide details on how to query the above proofs, @@ -144,7 +157,7 @@ Also, make sure to update the versions to match the latest ### 1. Data root inclusion proof -To prove the data root is committed to by the Blobstream X smart +To prove the data root is committed to by the Blobstream smart contract, we will need to provide a Merkle proof of the data root tuple to a data root tuple root. This can be created using the [`data_root_inclusion_proof`](https://github.com/celestiaorg/celestia-core/blob/c3ab251659f6fe0f36d10e0dbd14c29a78a85352/rpc/client/http/http.go#L492-L511) @@ -154,7 +167,7 @@ This [endpoint](https://github.com/celestiaorg/celestia-core/blob/793ece9bbd732a allows querying a data root to data root tuple root proof. It takes a block `height`, a starting block, and an end block, then it generates the binary Merkle proof of the `DataRootTuple`, corresponding to that `height`, -to the `DataRootTupleRoot` which is committed to in the Blobstream X contract. +to the `DataRootTupleRoot` which is committed to in the Blobstream contract. #### HTTP query @@ -232,11 +245,13 @@ func main() { -### Full example of proving that a Celestia block was committed to by Blobstream X contract +### Full example of proving that a Celestia block was committed to by Blobstream contract
-```go +::: code-group + +```go [BlobstreamX] package main import ( @@ -364,7 +379,7 @@ func verify() error { fmt.Println("data root was not committed to by the BlobstreamX contract") return nil } - return nil + return nil } func VerifyDataRootInclusion( @@ -402,6 +417,14 @@ func VerifyDataRootInclusion( return valid, nil } ``` + +```go [SP1 Blobstream] +// Similar to Blobstream, except replace the BlobstreamX contract with SP1 Blobstream: +import { + sp1blobstreamwrapper "github.com/succinctlabs/sp1-blobstream/bindings" +} +``` +:::
@@ -715,12 +738,12 @@ struct SharesProof { NamespaceNode[] rowRoots; // The proofs of the rowRoots to the data root. BinaryMerkleProof[] rowProofs; - // The proof of the data root tuple to the data root tuple root that was posted to the BlobstreamX contract. + // The proof of the data root tuple to the data root tuple root that was posted to the Blobstream contract. AttestationProof attestationProof; } /// @notice Contains the necessary parameters needed to verify that a data root tuple -/// was committed to, by the BlobstreamX smart contract, at some specif nonce. +/// was committed to, by the Blobstream smart contract, at some specif nonce. struct AttestationProof { // the attestation nonce that commits to the data root tuple. uint256 tupleRootNonce; @@ -1001,11 +1024,11 @@ with `proofs` being `sharesProof.RowProof.Proofs`. ### `attestationProof` This is the proof of the data root to the data root tuple root, which is committed -to in the Blobstream X contract: +to in the Blobstream contract: ```solidity /// @notice Contains the necessary parameters needed to verify that a data root tuple -/// was committed to, by the BlobstreamX smart contract, at some specif nonce. +/// was committed to, by the Blobstream smart contract, at some specif nonce. struct AttestationProof { // the attestation nonce that commits to the data root tuple. uint256 tupleRootNonce; @@ -1016,7 +1039,7 @@ struct AttestationProof { } ``` -- `tupleRootNonce`: the nonce at which Blobstream X committed to the batch containing +- `tupleRootNonce`: the nonce at which Blobstream committed to the batch containing the block containing the data. - `tuple`: the `DataRootTuple` of the block: @@ -1081,7 +1104,7 @@ func toAttestationProof( ``` -With the `nonce` being the attestation nonce, which can be retrieved using `BlobstreamX` +With the `nonce` being the attestation nonce, which can be retrieved using `Blobstream` contract events. Check below for an example. And `height` being the Celestia Block height that contains the rollup data, along with the `blockDataRoot` being the data root of the block height. Finally, `dataRootInclusionProof` is the @@ -1094,9 +1117,9 @@ If the `dataRoot` or the `tupleRootNonce` is unknown during the verification: (`15` in this example endpoint), and taking the `data_hash` field from the response. - `tupleRootNonce`: can be retried via querying the - `BlobstreamXDataCommitmentStored` events from the BlobstreamX + data commitment stored events from the Blobstream contract and looking for the nonce attesting to the - corresponding data. An example: + corresponding data. ### Querying the proof's `tupleRootNonce` @@ -1104,7 +1127,8 @@ If the `dataRoot` or the `tupleRootNonce` is unknown during the verification:
-```go +::: code-group +```go [BlobstreamX] // get the nonce corresponding to the block height that contains the PayForBlob transaction // since BlobstreamX emits events when new batches are submitted, we will query the events // and look for the range committing to the blob @@ -1164,16 +1188,28 @@ If the `dataRoot` or the `tupleRootNonce` is unknown during the verification: return fmt.Errorf("couldn't find range containing the block height") } ``` + +```go [SP1 Blobstream] +// Similar to BlobstreamX, but instead of importing the BlobstreamX contract, +// import the SP1 Blobstream contract: +import { + sp1blobstreamwrapper "github.com/succinctlabs/sp1-blobstream/bindings" +} +// and use the `BlobstreamDataCommitmentStored` event instead. +``` +:::
### Listening for new data commitments -For listening for new `BlobstreamXDataCommitmentStored` events, sequencers can +For listening for new data commitment stored events, sequencers can use the `WatchDataCommitmentStored` as follows:
-```go +::: code-group + +```go [BlobstreamX] ethClient, err := ethclient.Dial("evm_rpc") if err != nil { return err @@ -1211,6 +1247,17 @@ use the `WatchDataCommitmentStored` as follows: } } ``` + +```go [SP1 Blobstream] +// Similar to BlobstreamX, but instead of importing the BlobstreamX contract, +// import the SP1 Blobstream contract: +import { + sp1blobstreamwrapper "github.com/succinctlabs/sp1-blobstream/bindings" +} +// and use the `BlobstreamDataCommitmentStored` event instead. +``` + +:::
@@ -1254,7 +1301,9 @@ Then, you can submit the fraud proof using golang as follows:
-```go +::: code-group + +```go [BlobstreamX] package main import ( @@ -1489,15 +1538,29 @@ func namespace(namespaceID []byte) *client.Namespace { } } ``` + +```go [SP1 Blobstream] +// Similar to BlobstreamX, but instead of importing the BlobstreamX contract, +// import the SP1 Blobstream contract: +import { + sp1blobstreamwrapper "github.com/succinctlabs/sp1-blobstream/bindings" +} +// and use the `BlobstreamDataCommitmentStored` event instead. +``` + +::: +
For the step (2), check the [rollup inclusion proofs documentation](https://github.com/celestiaorg/blobstream-contracts/blob/master/docs/inclusion-proofs.md) for more information. -For an example project that uses the above proof queries, checkout the +For an example BlobstreamX project that uses the above proof queries, checkout the [blobstreamx-example](https://github.com/CryptoKass/blobstreamx-example) sample project. +Learn more on the [Lightlink docs](https://docs.lightlink.io/lightlink-protocol/achitecture-and-design/lightlink-protocol-deep-dive#id-5.-hummingbird). + ## Conclusion After creating all the proofs, and verifying them: diff --git a/developers/blobstream-x-requesting-data-commitment-ranges.md b/developers/blobstream-x-requesting-data-commitment-ranges.md index be35b67a653..300afacb95c 100644 --- a/developers/blobstream-x-requesting-data-commitment-ranges.md +++ b/developers/blobstream-x-requesting-data-commitment-ranges.md @@ -1,7 +1,7 @@ --- prev: - text: "Querying the Blobstream proofs" - link: "/developers/blobstream-proof-queries" + text: "Overview of Blobstream X" + link: "/developers/blobstreamx" --- # Requesting data commitment ranges @@ -32,7 +32,7 @@ Alternatively, if a team needs a very specific cadence that starts at very speci BlobstreamX contract and submit proofs to it. Deployment instructions can be found in the [BlobstreamX deploy](./blobstream-x-deploy.md) documentation. -::: Note +::: tip Requires a large cloud machine to run in a reasonable amount of time. EC2 r6a.16xlarge, i.e., 64CPU 512GB RAM, takes ~30 minutes to generate a header range proof. @@ -54,7 +54,7 @@ to run the operator script. Here are example values for the `.env` file: 1. `TENDERMINT_RPC_URL` from - [the public Celestia list](https://docs.celestia.org/nodes/mainnet#consensus-nodes). + [the public Celestia list](https://docs.celestia.org/nodes/mainnet#integrations). 2. `SUCCINCT_RPC_URL` = `https://alpha.succinct.xyz/api` 3. Request for `SUCCINCT_API_KEY` from [the Succinct team](https://alpha.succinct.xyz/partner). diff --git a/developers/blobstream.md b/developers/blobstream.md index 8cec66bf0a2..4e5b0fbbc0d 100644 --- a/developers/blobstream.md +++ b/developers/blobstream.md @@ -24,9 +24,18 @@ validity of Celestia block headers on a target EVM chain using zero-knowledge (Z proofs, which allow inheriting all the security guarantees of Celestia. +The latest implementation of Blobstream X is [SP1 Blobstream](https://github.com/succinctlabs/sp1-blobstream), +which is written in Rust for the SP1 zkVM. SP1 Blobstream offers improved performance and +efficiency while maintaining the security guarantees of the original Blobstream X. + Please note: Blobstream remains early-stage, experimental software and users should use Blobstream at their own risk. +### Implementations of Blobstream + +* [SP1 Blobstream](#what-is-sp1-blobstream) (an implementation of Blobstream X) +* [Blobstream X](#what-is-blobstream-x) + ## Blobstream vs. data availability committees (DACs) ### Decentralization and security @@ -57,9 +66,12 @@ In summary, both Blobstream and DACs aim to ensure offchain data availability, but Blobstream offers a more decentralized, secure, and scalable solution compared to the potential centralized nature of DACs. -## What is Blobstream X? +## What is SP1 Blobstream? -Blobstream X is an implementation of Blobstream with a +[SP1 Blobstream](https://github.com/succinctlabs/sp1-blobstream) is the latest implementation of Blobstream +in Rust using the [SP1](https://github.com/succinctlabs/sp1) zkVM. + +[SP1 Blobstream](https://github.com/succinctlabs/sp1-blobstream) is the latest implementation of Blobstream with a ZK light client that bridges Celestia’s modular DA layer to Ethereum to allow high-throughput rollups to use Celestia’s DA while settling on Ethereum. @@ -72,81 +84,51 @@ the Celestia network. Bridging Celestia’s data root to Ethereum requires running a Celestia _light client_ as a smart contract on Ethereum, to make the latest state -of the Celestia chain known on Ethereum and available to rollups. Blobstream -X utilizes the latest advances in ZK proofs to generate a +of the Celestia chain known on Ethereum and available to rollups. SP1 Blobstream +uses the latest advances in ZK proofs to generate a _succinct proof_ that enough Celestia validators have come to consensus (according to the CometBFT consensus protocol) on a block header, and -verifies this proof in the Blobstream X Ethereum smart contract to update +verifies this proof in the SP1 Blobstream Ethereum smart contract to update it with the latest Celestia header. -The Blobstream X ZK proof not only verifies the consensus of +The SP1 Blobstream ZK proof not only verifies the consensus of Celestia validators, but it also merkelizes and hashes all the data roots in the block range from the previous update to the current update, making accessible all Celestia data roots (verifiable with a Merkle inclusion proof against the stored Merkle root) to rollups. -Blobstream X is built and deployed with -[Succinct's protocol](https://platform-docs.succinct.xyz). +If you're looking to deploy SP1 blobstream to a new chain, +see [new Sp1 Blobstream deployments](./sp1-blobstream-deploy.md). + +Learn more at the [sp1-blobstream](https://github.com/succinctlabs/sp1-blobstream) +repo. -![blobstream x draft diagram](/img/blobstream/Celestia_Blobstream_X1b.png) +:::tip NOTE +The current Blobstream deployments all use SP1 Blobstream. +::: -## Integrate with Blobstream X +## Integrate with SP1 Blobstream -The following docs go over how developers can integrate Blobstream X. +The following docs go over how developers can integrate SP1 Blobstream. -You can [find the repository for Blobstream X](https://github.com/succinctlabs/blobstreamx) +You can [find the repository for SP1 Blobstream](https://github.com/succinctlabs/sp1-blobstream) along with code for: -- [The Blobstream X smart contract - `BlobstreamX.sol`](https://github.com/succinctlabs/blobstreamx/blob/main/contracts/src/BlobstreamX.sol) -- [The Blobstream X circuits](https://alpha.succinct.xyz/celestia/blobstreamx) -- [The Blobstream X contract Golang bindings](https://github.com/succinctlabs/blobstreamx/blob/main/bindings/BlobstreamX.go) +- [The SP1 Blobstream smart contract - `SP1Blobstream.sol`](https://github.com/succinctlabs/sp1-blobstream/blob/main/contracts/src/SP1Blobstream.sol) +- [The SP1 program](https://github.com/succinctlabs/sp1-blobstream/tree/main/program) +- [The SP1 Blobstream contract Golang bindings](//TODO) -The first deployments of Blobstream X will be maintained on the +The first deployments of SP1 Blobstream will be maintained on the following chains: Arbitrum One, Base and Ethereum Mainnet. Every 1 -hour, the prover/relayer will post an update to the Blobstream X contract +hour, the prover/relayer will post an update to the Blobstream contract that will include a new data commitment range that covers a 1-hour -block range from the `latestBlock` in the Blobstream X contract. -On Ethereum Mainnet, the Blobstream X contract will be updated +block range from the `latestBlock` in the contract. +On Ethereum Mainnet, the contract will be updated every 4 hours. -:::tip NOTE -Custom ranges can be requested using the `BlobstreamX` contract -to create proofs for specific Celestia block batches. These ranges -can be constructed as `[latestBlock, customTargetBlock)`, with -`latestBlock` as the latest block height that was committed to by the -`BlobstreamX` contract, and `latestBlock > customTargetBlock`, -and `customTargetBlock - latestBlock <= DATA_COMMITMENT_MAX`. - -Block ranges that are before the contract's `latestBlock` can't be -proven a second time in different batches. - -More information can be found in the [`requestHeaderRange(...)`](https://github.com/succinctlabs/blobstreamx/blob/364d3dc8c8dc9fd44b6f9f049cfb18479e56cec4/contracts/src/BlobstreamX.sol#L78-L101) -method. -::: - -### How Blobstream X works - -As shown in the diagram below, the entrypoint for updates to the Blobstream -X contract is through the `SuccinctGateway` smart contract, which is a -simple entrypoint contract that verifies proofs (against a deployed -onchain verifier for the Blobstream X circuit) and then calls the -`BlobstreamX.sol` contract to update it. -[Find more information about the `SuccinctGateway`](https://platform-docs.succinct.xyz/platform/onchain-integration#succinct-gateway). - -![blobstream x overview diagram draft](/img/blobstream/Celestia_Blobstream_X2b.png) +### How to integrate with Blobstream - - -:::tip NOTE -If the Blobstream X contract is not deployed on a desired chain, -it needs to be deployed before it can be used by your rollup. See the -[deployment documentation](https://platform-docs.succinct.xyz/platform/onchain-integration#non-canonical-chain-contract-deployment) -for more details. -::: - -### How to integrate with Blobstream X - -Integrating your L2 with Blobstream X requires two components: your +Integrating your L2 with Blobstream requires two components: your [onchain smart contract logic](./blobstream-contracts.md), and your [offchain client logic for your rollup](./blobstream-offchain.md). The next three sections cover these @@ -163,31 +145,17 @@ More on the different ways to build a blobstream rollup can be found in the ### Deployed contracts -You can interact with the Blobstream X contracts today. The -Blobstream X Solidity smart contracts are currently deployed on +You can interact with the SP1 Blobstream contracts today. The +SP1 Blobstream Solidity smart contracts are currently deployed on the following chains: -::: warning -Blobstream X is in beta and slashing is not enabled yet. -::: - -| Contract | EVM network | Contract address | Attested data on Celestia | Link to Celenium | -| ------------ | ---------------- | ------------------------------------------------------------------------------------------------------------------------------- | ------------- | ------------- | -| Blobstream X | Ethereum Mainnet | [`0x7Cf3876F681Dbb6EdA8f6FfC45D66B996Df08fAe`](https://etherscan.io/address/0x7Cf3876F681Dbb6EdA8f6FfC45D66B996Df08fAe#events) | [Mainnet Beta](../nodes/mainnet.md) | [Deployment on Celenium](https://celenium.io/blobstream?network=ethereum&page=1) | -| Blobstream X | Arbitrum One | [`0xA83ca7775Bc2889825BcDeDfFa5b758cf69e8794`](https://arbiscan.io/address/0xA83ca7775Bc2889825BcDeDfFa5b758cf69e8794#events) | [Mainnet Beta](../nodes/mainnet.md) | [Deployment on Celenium](https://celenium.io/blobstream?network=arbitrum&page=1) | -| Blobstream X | Base | [`0xA83ca7775Bc2889825BcDeDfFa5b758cf69e8794`](https://basescan.org/address/0xA83ca7775Bc2889825BcDeDfFa5b758cf69e8794#events) | [Mainnet Beta](../nodes/mainnet.md) | [Deployment on Celenium](https://celenium.io/blobstream?network=base&page=1) | -| Blobstream X | Sepolia | [`0xf0c6429ebab2e7dc6e05dafb61128be21f13cb1e`](https://sepolia.etherscan.io/address/0xf0c6429ebab2e7dc6e05dafb61128be21f13cb1e#events) | [Mocha testnet](../nodes/mocha-testnet.md) | [Deployment on Celenium](https://mocha-4.celenium.io/blobstream?network=ethereum&page=1) | -| Blobstream X | Arbitrum Sepolia | [`0xc3e209eb245Fd59c8586777b499d6A665DF3ABD2`](https://sepolia.arbiscan.io/address/0xc3e209eb245Fd59c8586777b499d6A665DF3ABD2#events) | [Mocha testnet](../nodes/mocha-testnet.md) | [Deployment on Celenium](https://mocha-4.celenium.io/blobstream?network=arbitrum&page=1) | -| Blobstream X | Base Sepolia | [`0xc3e209eb245Fd59c8586777b499d6A665DF3ABD2`](https://sepolia.basescan.org/address/0xc3e209eb245Fd59c8586777b499d6A665DF3ABD2#events) | [Mocha testnet](../nodes/mocha-testnet.md) | [Deployment on Celenium](https://mocha-4.celenium.io/blobstream?network=base&page=1) | - -## Deploy Blobstream X - -If your target chain is [still not supported](#deployed-contracts), it is possible to deploy and maintain a Blobstream x instance and have the same security guarantees. - -First, you will need to create a multisig that governs the Blobstream X contract and also the function identifiers. The function identifiers can be registered in the [Succinct gateway](https://platform-docs.succinct.xyz/platform/onchain-integration#register-circuits-with-your-deployed-succinct-gateway). - -Then, check the [deployment](https://github.com/succinctlabs/blobstreamx/blob/main/README.md#blobstreamx-contract-overview) documentation for how to deploy the contract. - -Then, you will need to run a relayer, which will generate the proofs and relay them to your deployed Blobstream X contract. Check the [local proving documentation](./blobstream-x-requesting-data-commitment-ranges.md#local-proving) for more information. +| Contract | EVM network | Contract address | Attested data on Celestia | Link to Celenium | +|----------------| ---------------- | ------------------------------------------------------------------------------------------------------------------------------- | ------------- | ------------- | +| SP1 Blobstream | Ethereum Mainnet | [`0x7Cf3876F681Dbb6EdA8f6FfC45D66B996Df08fAe`](https://etherscan.io/address/0x7Cf3876F681Dbb6EdA8f6FfC45D66B996Df08fAe#events) | [Mainnet Beta](../nodes/mainnet.md) | [Deployment on Celenium](https://celenium.io/blobstream?network=ethereum&page=1) | +| SP1 Blobstream | Arbitrum One | [`0xA83ca7775Bc2889825BcDeDfFa5b758cf69e8794`](https://arbiscan.io/address/0xA83ca7775Bc2889825BcDeDfFa5b758cf69e8794#events) | [Mainnet Beta](../nodes/mainnet.md) | [Deployment on Celenium](https://celenium.io/blobstream?network=arbitrum&page=1) | +| SP1 Blobstream | Base | [`0xA83ca7775Bc2889825BcDeDfFa5b758cf69e8794`](https://basescan.org/address/0xA83ca7775Bc2889825BcDeDfFa5b758cf69e8794#events) | [Mainnet Beta](../nodes/mainnet.md) | [Deployment on Celenium](https://celenium.io/blobstream?network=base&page=1) | +| SP1 Blobstream | Sepolia | [`0xf0c6429ebab2e7dc6e05dafb61128be21f13cb1e`](https://sepolia.etherscan.io/address/0xf0c6429ebab2e7dc6e05dafb61128be21f13cb1e#events) | [Mocha testnet](../nodes/mocha-testnet.md) | [Deployment on Celenium](https://mocha-4.celenium.io/blobstream?network=ethereum&page=1) | +| SP1 Blobstream | Arbitrum Sepolia | [`0xc3e209eb245Fd59c8586777b499d6A665DF3ABD2`](https://sepolia.arbiscan.io/address/0xc3e209eb245Fd59c8586777b499d6A665DF3ABD2#events) | [Mocha testnet](../nodes/mocha-testnet.md) | [Deployment on Celenium](https://mocha-4.celenium.io/blobstream?network=arbitrum&page=1) | +| SP1 Blobstream | Base Sepolia | [`0xc3e209eb245Fd59c8586777b499d6A665DF3ABD2`](https://sepolia.basescan.org/address/0xc3e209eb245Fd59c8586777b499d6A665DF3ABD2#events) | [Mocha testnet](../nodes/mocha-testnet.md) | [Deployment on Celenium](https://mocha-4.celenium.io/blobstream?network=base&page=1) | diff --git a/developers/blobstreamx.md b/developers/blobstreamx.md new file mode 100644 index 00000000000..83c56819001 --- /dev/null +++ b/developers/blobstreamx.md @@ -0,0 +1,78 @@ +--- +description: What is BlobstreamX +prev: + text: "New SP1 Blobstream deployments" + link: "/developers/sp1-blobstream-deploy" +next: + text: "Requesting data commitment ranges" + link: "/developers/blobstream-x-requesting-data-commitment-ranges" +--- + +# Blobstream X: the previous zk implementation of Blobstream + +![blobstream x draft diagram](/img/blobstream/Celestia_Blobstream_X1b.png) + +## What is Blobstream X? + +Blobstream X is the previous implementation of Blobstream. It uses +[plonky2x](https://github.com/succinctlabs/succinctx/tree/main/plonky2x) to create +circuits that verify the Celestia consensus and generate the corresponding proofs. + +Blobstream X is built and deployed with +[Succinct's protocol](https://platform-docs.succinct.xyz). + +:::tip NOTE +The Blobstream deployments below don't use the BlobstreamX circuits. +::: + +You can [find the repository for Blobstream X](https://github.com/succinctlabs/blobstreamx) +along with code for: + +- [The Blobstream X smart contract - `BlobstreamX.sol`](https://github.com/succinctlabs/blobstreamx/blob/main/contracts/src/BlobstreamX.sol) +- [The Blobstream X circuits](https://alpha.succinct.xyz/celestia/blobstreamx) +- [The Blobstream X contract Golang bindings](https://github.com/succinctlabs/blobstreamx/blob/main/bindings/BlobstreamX.go) + +:::tip NOTE +Custom ranges can be requested using the `BlobstreamX` contract +to create proofs for specific Celestia block batches. These ranges +can be constructed as `[latestBlock, customTargetBlock)`, with +`latestBlock` as the latest block height that was committed to by the +`BlobstreamX` contract, and `latestBlock > customTargetBlock`, +and `customTargetBlock - latestBlock <= DATA_COMMITMENT_MAX`. + +Block ranges that are before the contract's `latestBlock` can't be +proven a second time in different batches. + +More information can be found in the [`requestHeaderRange(...)`](https://github.com/succinctlabs/blobstreamx/blob/364d3dc8c8dc9fd44b6f9f049cfb18479e56cec4/contracts/src/BlobstreamX.sol#L78-L101) +method. +::: + +## How Blobstream X works + +As shown in the diagram below, the entrypoint for updates to the Blobstream +X contract is through the `SuccinctGateway` smart contract, which is a +simple entrypoint contract that verifies proofs (against a deployed +onchain verifier for the Blobstream X circuit) and then calls the +`BlobstreamX.sol` contract to update it. +[Find more information about the `SuccinctGateway`](https://platform-docs.succinct.xyz/platform/onchain-integration#succinct-gateway). + +![blobstream x overview diagram draft](/img/blobstream/Celestia_Blobstream_X2b.png) + + + +:::tip NOTE +If the Blobstream X contract is not deployed on a desired chain, +it needs to be deployed before it can be used by your rollup. See the +[deployment documentation](https://platform-docs.succinct.xyz/platform/onchain-integration#non-canonical-chain-contract-deployment) +for more details. +::: + +## Deploy Blobstream X + +It is possible to deploy and maintain a Blobstream x instance and have the same security guarantees. + +First, you will need to create a multisig that governs the Blobstream X contract and also the function identifiers. The function identifiers can be registered in the [Succinct gateway](https://platform-docs.succinct.xyz/platform/onchain-integration#register-circuits-with-your-deployed-succinct-gateway). + +Then, check the [deployment](https://github.com/succinctlabs/blobstreamx/blob/main/README.md#blobstreamx-contract-overview) documentation for how to deploy the contract. + +Then, you will need to run a relayer, which will generate the proofs and relay them to your deployed Blobstream X contract. Check the [local proving documentation](./blobstream-x-requesting-data-commitment-ranges.md#local-proving) for more information. diff --git a/developers/bubs-testnet.md b/developers/bubs-testnet.md index 7634d3e5de4..509fdd4760a 100644 --- a/developers/bubs-testnet.md +++ b/developers/bubs-testnet.md @@ -1,8 +1,8 @@ --- description: The first testnet built with OP Stack and Celestia. next: - text: "Deploy a smart contract on Bubs testnet" - link: "/developers/deploy-on-bubs" + text: "Ethereum fallback mechanism" + link: "/developers/ethereum-fallback" --- # Bubs testnet diff --git a/developers/build-whatever.md b/developers/build-whatever.md index f335723fcb9..aa283d54506 100644 --- a/developers/build-whatever.md +++ b/developers/build-whatever.md @@ -28,7 +28,7 @@ Here are a few options that are currently available for developers. - + diff --git a/developers/deploy-on-bubs.md b/developers/deploy-on-bubs.md deleted file mode 100644 index e275eb6dbca..00000000000 --- a/developers/deploy-on-bubs.md +++ /dev/null @@ -1,278 +0,0 @@ ---- -prev: - text: "Bubs testnet" - link: "/developers/bubs-testnet" ---- - -# Deploy a smart contract on Bubs testnet - -In this tutorial, we will deploy a smart contract to the -Bubs testnet. - -## Dependencies - -- [Foundry](https://getfoundry.sh/) installed on your machine -- [Node.js](https://nodejs.org/en) -- Basic understanding of Ethereum -- Basic understanding of Solidity and Node.js -- Bubs ETH from the [Bubs faucet](https://bubs-sepolia.hub.caldera.xyz/) or -[Bubs bridge](https://bubs-sepolia.bridge.caldera.xyz/) -- A Bubs RPC URL from the [Bubs testnet page](./bubs-testnet.md) - -## Setup - -First, in your `$HOME` directory, set up a new project folder for this -tutorial and init the project with npm: - -```bash -cd $HOME -mkdir counter-project && cd counter-project && npm init -y -``` - -Next, initialize a Foundry project with the following command: - -```bash -forge init counter_contract -``` - -## Create your smart contract - -Take a look at the `Counter.sol` file in your -`counter-project/counter_contract/src` directory: - -```solidity -// SPDX-License-Identifier: UNLICENSED -pragma solidity ^0.8.13; - -contract Counter { - uint256 public number; - - function setNumber(uint256 newNumber) public { - number = newNumber; - } - - function increment() public { - number++; - } -} -``` - -The contract contains a public unsigned integer variable named "number". -There are two public functions in this contract. The `setNumber` function -allows anyone to set a new value for the "number" variable, while the -`increment` function increases the value of "number" by one each time it's -called. - -You can -[learn more about Solidity and smart contract programming](https://ethereum.org/en/developers/learning-tools/). - -To compile the contract, run the following forge command from the -`$HOME/counter-project/counter_contract/` directory: - -```bash -forge build -``` - -Your output should look similar to the following: - -```bash -[⠢] Compiling... -[⠔] Compiling 21 files with 0.8.19 -[⠑] Solc 0.8.19 finished in 1.24s -Compiler run successful -``` - -## Test your smart contract - -Now, open the `test/Counter.t.sol` file: - -```solidity -// SPDX-License-Identifier: UNLICENSED -pragma solidity ^0.8.13; - -import "forge-std/Test.sol"; -import "../src/Counter.sol"; - -contract CounterTest is Test { - Counter public counter; - - function setUp() public { - counter = new Counter(); - counter.setNumber(0); - } - - function testIncrement() public { - counter.increment(); - assertEq(counter.number(), 1); - } - - function testSetNumber(uint256 x) public { - counter.setNumber(x); - assertEq(counter.number(), x); - } -} -``` - -This file performs unit testing on the contract we created in the previous -section. Here's what the test is doing: - -- The contract includes a public "Counter" type variable called "counter". - In the `setUp` function, it initializes a new instance of the "Counter" - contract and sets the "number" variable to 0. - -- There are two test functions in the contract: `testIncrement` and - `testSetNumber`. - -- The `testIncrement` function tests the "increment" function of the - "Counter" contract by calling it and then asserting that the "number" in - the "Counter" contract is 1. It verifies if the increment operation - correctly increases the number by one. - -- The `testSetNumber` function is more generic. It takes an unsigned integer - argument 'x' and tests the "setNumber" function of the "Counter" contract. - After calling the "setNumber" function with 'x', it asserts that the - "number" in the "Counter" contract is equal to 'x'. This verifies that the - "setNumber" function correctly updates the "number" in the "Counter" - contract. - -Now, to test your code, run the following: - -```bash -forge test -``` - -If the test is successful, your output should be similar to this: - -```bash -[⠆] Compiling... -No files changed, compilation skipped - -Running 2 tests for test/Counter.t.sol:CounterTest -[PASS] testIncrement() (gas: 28334) -[PASS] testSetNumber(uint256) (runs: 256, μ: 27709, ~: 28409) -Test result: ok. 2 passed; 0 failed; finished in 8.96ms -``` - -## Deploying your smart contract - -### Using Anvil - -First, we'll test out our contract on a local devnet called "anvil". To start -the local server, run: - -```bash -anvil -``` - -You'll see a local RPC endpoint (`127.0.0.1:8545`) and accounts to test with. - -Let's deploy the contract now. First, set a private key from anvil: - -```bash -export PRIVATE_KEY=0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80 -export ANVIL_RPC_URL=http://localhost:8545 -``` - -Now, deploy the contract: - -```bash -forge create --rpc-url $ANVIL_RPC_URL \ ---private-key $PRIVATE_KEY \ -src/Counter.sol:Counter -``` - -### Using Bubs - -First, set a private key from your funded Ethereum wallet and -set the `BUBS_RPC_URL` variable with an -[RPC of your choosing](./bubs-testnet.md#rpc-urls): - -```bash -export BUBS_PRIVATE_KEY=0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80 -export BUBS_RPC_URL=https://bubs-sepolia.rpc.caldera.xyz/http -``` - -Now that we're ready to deploy the smart contract onto Bubs, we will run -the `forge create` command. - -```bash -forge create --rpc-url $BUBS_RPC_URL \ ---private-key $BUBS_PRIVATE_KEY \ -src/Counter.sol:Counter -``` - -A successful deployment will return output similar to below: - -```bash -[⠆] Compiling... -No files changed, compilation skipped -Deployer: 0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266 -Deployed to: 0x5FbDB2315678afecb367f032d93F642f64180aa3 -Transaction hash: 0xf1a793a793cd9fc588f5132d99008565ea361eb3535d66499575e9e1908200b2 -``` - -Once you've deployed the contract, you're ready to interact with it! - -First, we'll set it as a variable: - -```bash -export CONTRACT_ADDRESS=0x5FbDB2315678afecb367f032d93F642f64180aa3 -``` - -## Interacting with your smart contract - -Foundry uses `cast`, a CLI for performing Ethereum RPC calls. - -To write to the contract, we'll use the `cast send` command: - - - -```bash -cast send $CONTRACT_ADDRESS "setNumber(uint256)" 10 --rpc-url $BUBS_RPC_URL --private-key $BUBS_PRIVATE_KEY -``` - - - -Your output will look similar: - -```bash -blockHash 0x131822bef6eb59656d7e1387c19b75be667e587006710365ec5cf58030786c42 -blockNumber 3 -contractAddress -cumulativeGasUsed 43494 -effectiveGasPrice 3767182372 -gasUsed 43494 -logs [] -logsBloom 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 -root -status 1 -transactionHash 0x8f15d6004598f0662dd673a9898dceef77be8cc28408cecc284b28d7be32307d -transactionIndex 0 -type 2 -``` - -Now, we can make a read call to view the state of the number variable, -using the `cast call` command: - -```bash -cast call $CONTRACT_ADDRESS "number()" --rpc-url $BUBS_RPC_URL -``` - -The result will look similar: - -```bash -0x000000000000000000000000000000000000000000000000000000000000000a -``` - -Convert the result from hexadecimal to a base 10 value with: - -```bash -echo $((0x000000000000000000000000000000000000000000000000000000000000000a)) -``` - -## Next steps - -Congratulations! You've learned how to deploy a smart contract to Bubs testnet. - -What will you build next? Now, you're ready to check out the -[GM Portal tutorial](./gm-portal-bubs.md). diff --git a/developers/feegrant-for-blobs.md b/developers/feegrant-for-blobs.md index dcbeddea878..e4ba39be0f0 100644 --- a/developers/feegrant-for-blobs.md +++ b/developers/feegrant-for-blobs.md @@ -42,63 +42,36 @@ export RPC_URL=rpc.celestia-mocha.com ### FeeGrant module implementation in celestia-node -Using celestia-node, you now can easily give permission for +Using celestia-node, you can now easily give permission for other nodes to submit transactions on your behalf. It is also possible to revoke the grant. -The node that receives the grant has to run a node with the -`--granter.address=$GRANTER_ADDRESS>` flag to use FeeGrant functionality. - -The granter address will be stored until the next run of your local node. -So, in case the granter revokes permission, you will have to restart the -node without this flag. - -::: tip -Transactions paid for by the the FeeGrant module will consume more gas than -regular `PayForBlobs` transactions. - -| Fee and transaction type | Transaction 1 | Transaction 2 | -|--------------------------------|----------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------| -| 0.000176 fee with feegrant on Mocha testnet | [Link](https://mocha.celenium.io/tx/82384c8006c6cf73072ffeb160f78c659447dba1757e4a4f6d5e6684935acc61) | [Link](https://mocha.celenium.io/tx/83fa70a496eaf4fa21da43c88c1f0bf8f9aa6676ec1d47f183fca948ab418f94) | -| 0.00016 fee without feegrant on Mocha testnet | [Link](https://mocha.celenium.io/tx/9e15dcf7e82288bdf0efc06edf92a30eead60d5ed6518a4721fee1bc34613e2c) | [Link](https://mocha.celenium.io/tx/a670112dee5bc2001b18225587f2cce86c97016a87d33cc1425b755518050348) | - -::: +The FeeGrant functionality can now be used during runtime without +the need to restart the node. ### Grant permission for an allowance as a granter -First, your node will need to be running with a command similar to: +First, start your node: ```bash -celestia light start --p2p.network mocha --core.ip $RPC_URL \ - --keyring.keyname granter_key +celestia light start --p2p.network mocha --core.ip $RPC_URL ``` Then, grant the fee to the grantee: ```bash -celestia state grant-fee $GRANTEE_ADDRESS 2000 1000000 +celestia state grant-fee $GRANTEE_ADDRESS --amount 2000 ``` -Note that the `--amount uint` flag specifies the spend limit (in utia) for the -grantee. The default value is 0 which means the grantee does not have a spend -limit. - -To set a limit of 42069 utia, use the following command: - -```bash -celestia state grant-fee $GRANTEE_ADDRESS 2000 1000000 \ - --amount 42069 -``` - -Find the [example transaction on Celenium](https://mocha.celenium.io/tx/532c2d63b0732e335def1cb7f805bb798793fda43f88a955c5a9224dc6d0433e). +Note that the `--amount` flag specifies the spend limit (in utia) for the +grantee. If not specified, the grantee does not have a spend limit. ## Using a FeeGrant allowance as a grantee in celestia-node -First, start your node with the grantee account: +Start your node: ```bash celestia light start --core.ip $RPC_URL --p2p.network=mocha - --granter.address=$GRANTER_ADDRESS ``` To check the balance of a light node, use the following command: @@ -120,10 +93,10 @@ Example response when the account balance does not exist: This indicates that the light node currently does not have any funds. -Now submit a blob: +Now submit a blob using the FeeGrant: ```bash -celestia blob submit 0x42690c204d39600fddd3 0x6665656772616e74 +celestia blob submit 0x42690c204d39600fddd3 'gm' --granter.address $GRANTER_ADDRESS ``` You'll see the height and the commitment of your blob: @@ -139,10 +112,6 @@ You'll see the height and the commitment of your blob: } ``` -After the transactions made making this guide, -[see that the account balance is still 0 utia](https://mocha.celenium.io/address/celestia1e500l0nlwqj7x5vsqcxqd8rns5khvfw0skgu60). - - ## Checking account balances after submission Light node account: @@ -167,19 +136,12 @@ Example output showing fees are not deducted: ## Optional: Revoke permission for a FeeGrant allowance as a granter -To revoke the feegrant, run your light node as the granter and run: +To revoke the feegrant, run: ```bash -celestia state revoke-grant-fee $GRANTEE_ADDRESS 2000 1000000 +celestia state revoke-grant-fee $GRANTEE_ADDRESS ``` -There is also a specific error for the case when you run your node as a -grantee, but the granter revokes their permission. In this case, your transaction will -fail with the error: `granter has revoked the grant` -This will mean that you have to restart the node without the `granter.address` -flag. - - ### Optional: Submitting a blob from file input To submit a blob from file input: diff --git a/developers/full-stack-modular-development-guide.md b/developers/full-stack-modular-development-guide.md deleted file mode 100644 index 58994f270ec..00000000000 --- a/developers/full-stack-modular-development-guide.md +++ /dev/null @@ -1,811 +0,0 @@ ---- -description: Learn to build a full stack modular dapp. ---- - -# Full stack modular blockchain development guide - -:::tip Note -This tutorial needs to be updated -::: - -This guide will introduce you to -[modular blockchains](../learn/how-celestia-works/introduction.md) like -Celestia, explain their benefits, and show you how to build a full stack -modular dapp with React, Vite, RainbowKit, Celestia, and Foundry. - -Current blockchain architectures are not scalable and face challenges -around accessibility. In order for blockchains and web3 to reach mass -adoption, these challenges must be addressed. - -Blockchains have evolved over time from application-specific networks like -Bitcoin to shared smart contract platforms like Ethereum. This guide will -cover how to build dapps on these newer, shared platforms. - -If you're interested in learning more about modular blockchains, or are new -to the Celestia ecosystem, we recommend you read the -[build whatever page](./build-whatever.md) first. - -## Getting started - -Now that you’ve had an overview of what Celestia is, let’s start building! - -The execution environment that we’ll be leveraging today is Ethermint, an -EVM-compatible testnet that you will run locally for this tutorial. - -### Pre-requisites - -- [Node.js](https://github.com/nvm-sh/nvm) -- [Foundry](https://github.com/foundry-rs/foundry) -- [Infura account](https://infura.io) (for uploading files to IPFS) -- [A Celestia light node running](./node-tutorial.md) (to post PFBs from your - rollup) -- EVM Tutorial (Coming soon!) - for - running your own EVM rollup & deploying your smart contract -- [MetaMask wallet](https://metamask.io) (for connecting to your frontend) - -### Project setup - -To get started, create a new Foundry project: - -```bash -forge init celestia-dapp -cd celestia-dapp -``` - -Foundry has created an example smart contract located at `src/Contract.sol`. - -#### Updating the contract and tests - -Let's update the contracts to include a basic blog example. Create a new file -in the `src` directory named `Contract.sol` with the following code: - - - -```solidity title="src/Contract.sol" -// SPDX-License-Identifier: MIT -pragma solidity ^0.8.13; - -contract Blog { - string public name; - address public owner; - - uint private _postId; - - struct Post { - uint id; - string title; - string content; - bool published; - } - /* mappings can be seen as hash tables */ - /* here we create lookups for posts by id and posts by ipfs hash */ - mapping(uint => Post) private idToPost; - mapping(string => Post) private hashToPost; - - /* events facilitate communication between smart contracts and their user interfaces */ - /* i.e. we can create listeners for events in the client and also use them in The Graph */ - event PostCreated(uint id, string title, string hash); - event PostUpdated(uint id, string title, string hash, bool published); - - /* when the blog is deployed, give it a name */ - /* also set the creator as the owner of the contract */ - constructor(string memory _name) { - name = _name; - owner = msg.sender; - } - - /* updates the blog name */ - function updateName(string memory _name) public { - name = _name; - } - - /* transfers ownership of the contract to another address */ - function transferOwnership(address newOwner) public onlyOwner { - owner = newOwner; - } - - /* fetches an individual post by the content hash */ - function fetchPost(string memory hash) public view returns(Post memory){ - return hashToPost[hash]; - } - - /* creates a new post */ - function createPost(string memory title, string memory hash) public onlyOwner { - _postId = _postId + 1; - Post storage post = idToPost[_postId]; - post.id = _postId; - post.title = title; - post.published = true; - post.content = hash; - hashToPost[hash] = post; - emit PostCreated(_postId, title, hash); - } - - /* updates an existing post */ - function updatePost(uint postId, string memory title, string memory hash, bool published) public onlyOwner { - Post storage post = idToPost[postId]; - post.title = title; - post.published = published; - post.content = hash; - idToPost[postId] = post; - hashToPost[hash] = post; - emit PostUpdated(post.id, title, hash, published); - } - - /* fetches all posts */ - function fetchPosts() public view returns (Post[] memory) { - uint itemCount = _postId; - - Post[] memory posts = new Post[](itemCount); - for (uint i = 0; i < itemCount; i++) { - uint currentId = i + 1; - Post storage currentItem = idToPost[currentId]; - posts[i] = currentItem; - } - return posts; - } - - /* this modifier means only the contract owner can */ - /* invoke the function */ - modifier onlyOwner() { - require(msg.sender == owner); - _; - } -} -``` - - - -Next, let's create a test for this contract. - -Open `test/Contract.t.sol` and update the code with the following: - -```solidity title="test/Contract.t.sol" -// SPDX-License-Identifier: MIT -pragma solidity ^0.8.13; - -import "forge-std/Test.sol"; -import "src/Contract.sol"; - -contract ContractTest is Test { - Blog blog; - - function setUp() public { - blog = new Blog("Celestia Blog"); - } - - function testCreatePost() public { - blog.createPost("My first post", "12345"); - Blog.Post[] memory posts = blog.fetchPosts(); - assertEq(posts.length, 1); - } - - function testUpdatePost() public { - blog.createPost("My first post", "12345"); - blog.updatePost(1, "My second post", "12345", true); - Blog.Post memory updatedPost = blog.fetchPost("12345"); - assertEq(updatedPost.title, "My second post"); - } - - function testFetchPosts() public { - Blog.Post[] memory posts = blog.fetchPosts(); - assertEq(posts.length, 0); - blog.createPost("My first post", "12345"); - posts = blog.fetchPosts(); - assertEq(posts.length, 1); - } - - function testOnlyOwner() public { - blog.createPost("My first post", "12345"); - address bob = address(0x1); - vm.startPrank(bob); - vm.expectRevert(); - blog.updatePost(1, "My second post", "12345", true); - } -} -``` - -Foundry uses [Dappsys Test](https://book.getfoundry.sh/reference/ds-test.html) -to provide basic logging and assertion functionality. It's included in the Forge -Standard Library. - -Here, we are using `assertEq` to assert equality. You can -[view all of the assertion functions available](https://book.getfoundry.sh/reference/ds-test.html?highlight=log_int#asserting). - -#### Running the test - -We can now run our tests to make sure our contract is working properly: - -```bash -forge test -vv -``` - -#### Updating the deployment script - -Now that we've tested the contract, let's try deploying it locally using -[Solidity Scripting](https://book.getfoundry.sh/tutorials/solidity-scripting.html). - -To do so, update the deployment script at `script/Contract.s.sol` with the -following code: - -```solidity title="script/Contract.s.sol" -// SPDX-License-Identifier: MIT -pragma solidity ^0.8.13; - -import "forge-std/Script.sol"; - -import {Blog} from "src/Contract.sol"; - -contract ContractScript is Script { - function setUp() public {} - - function run() public { - vm.startBroadcast(); - new Blog("Celestia Blog"); - vm.stopBroadcast(); - } -} -``` - -Now we can use this script to deploy our smart contract to either a live or test -network. - -#### Deploying locally - -Next start Anvil, the local testnet: - -```bash -anvil --port 9545 -``` - -:::danger caution - -We need to use port 9545, because Ethermint will use 8545. - -::: - -Once started, Anvil will give you a local RPC endpoint as well as a handful of -Private Keys and Accounts that you can use. - -We can now use the local RPC along with one of the private keys to deploy locally: - -```bash -forge script script/Contract.s.sol:ContractScript --fork-url \ -http://localhost:9545 --private-key $PRIVATE_KEY --broadcast -``` - -Once the contract has been deployed locally, Anvil will log out the contract address. - -**Take a note of this local contract address as we’ll be using it later in the -frontend application.** - -Next, set the contract address as an environment variable: - -```bash -export CONTRACT_ADDRESS= -``` - -We can then test sending transactions to it with `cast send`. - -```bash -cast send $CONTRACT_ADDRESS \ -"createPost(string,string)" "my first post" "12345" \ ---private-key $PRIVATE_KEY -``` - -We can then perform read operations with `cast call`: - -```bash -cast call $CONTRACT_ADDRESS "fetchPosts()" -``` - -Once the contract is deployed successfully, **take a note of the contract -address as we’ll also be needing it in just a moment when we test the live contract**. - -### Deploying to the Ethermint Sovereign Rollup - -First, we will need to follow the setup from the EVM tutorial. - -:::danger Pre-requisites - -It is required that you complete dependency setup, -Rollkit installation, and -Instantiating and EVM rollup from the -EVM tutorial -to complete the remainder of the tutorial. - -::: - -Now that we've deployed and tested locally, we can deploy to our -Ethermint chain. - -First, we will need to export the private key generated by -the ethermint `init.sh` script: - -```bash -PRIVATE_KEY=$(ethermintd keys unsafe-export-eth-key mykey --keyring-backend test) -``` - -:::tip NOTE -Here, the key name from `init.sh` is `mykey` but you can modify -the `init.sh` to change the name of your key. -::: - -Now, we can start deploying the smart contract to our Ethermint chain. - -To do so, run the following script in the `celestia-dapp` directory: - -```bash -forge script script/Contract.s.sol:ContractScript \ ---rpc-url http://localhost:8545 --private-key $PRIVATE_KEY --broadcast -``` - -Set the contract address in the output as the `CONTRACT_ADDRESS` variable: - -```bash -export CONTRACT_ADDRESS= -``` - -Once the contract has been deployed to the Ethermint rollup, we can -use `cast send` to test sending transactions to it: - -```bash -cast send $CONTRACT_ADDRESS \ -"createPost(string,string)" "my first post" "12345" \ ---rpc-url http://localhost:8545 --private-key $PRIVATE_KEY -``` - -We can then perform read operations with `cast call`: - -```bash -cast call $CONTRACT_ADDRESS "fetchPosts()" --rpc-url http://localhost:8545 -``` - -:::tip NOTE -You will want to redeploy the contract for your frontend, because -the post is not uploaded to IPFS in the CLI. -::: - -### Building the frontend - -For the frontend project, we’ll be using the following libraries and frameworks: - -[React](https://reactjs.org) - JavaScript library for building user interfaces - -[Vite](https://vitejs.dev) - Project generator / rapid development tool for -modern web projects - -[Rainbowkit](https://www.rainbowkit.com) - Easy and beautiful library to connect -a wallet - -[WAGMI](https://github.com/wagmi-dev/wagmi) - 20+ hooks for working with -wallets, ENS, contracts, transactions, signing, etc - -In the root of the Foundry project, create a new React.js application using [Vite](https://vitejs.dev): - -```jsx -yarn create vite - -? Project name: › frontend -? Select a framework › React -? Select a variant > JavaScript -``` - -Next, copy the ABI that was created by Foundry into the `frontend` directory so -that we can have it later (or manually copy it into a file named `Blog.json` in -the `frontend` directory): - -```bash -cp out/Contract.sol/Blog.json frontend/ -``` - -Now, change into the `frontend` directory and install the `node_modules`: - -```bash -cd frontend -yarn -``` - -#### Configuring environment variables - -Next we need to configure the environment variables for the Infura project ID -and secret. - -First, create an Infura account and new project for IPFS. - -Create a file named `.env.local` in the `frontend/` directory and add the following -configuration with your own credentials: - -```txt -VITE_INFURA_ID=your-project-api-key -VITE_INFURA_SECRET=your-project-api-key-secret -``` - -Now that the project is created, let’s install the additional dependencies using -either **NPM**, **Yarn**, or **PNPM**: - -```jsx -npm install @rainbow-me/rainbowkit@0.8.0 wagmi@0.8.10 ethers ipfs-http-client react-markdown -``` - -### Configuring the entrypoint - -Next we’ll update the entrypoint at `src/main.jsx`. - -The main things we’re doing here have to do with the configuration of Rainbowkit -so that we can have a nice way for the user to connect their wallet. - -Rainbowkit also allows a customizable array of network providers, so we’re -creating a new network configuration for `Ethermint`. - -```jsx title="frontend/src/main.jsx" -import "./polyfills"; -import ReactDOM from "react-dom/client"; -import App from "./App"; -import "./index.css"; -import "@rainbow-me/rainbowkit/styles.css"; -import { RainbowKitProvider } from "@rainbow-me/rainbowkit"; -import { chain, configureChains, createClient, WagmiConfig } from "wagmi"; -import { publicProvider } from "wagmi/providers/public"; -import { injectedWallet, metaMaskWallet } from "@rainbow-me/rainbowkit/wallets"; -import { connectorsForWallets } from "@rainbow-me/rainbowkit"; - -/* create configuration for Ethermint testnet */ -const ethermint = { - id: 9000, - name: "Ethermint", - network: "ethermint", - nativeCurrency: { - decimals: 18, - name: "Ethermint", - symbol: "CTE", - }, - rpcUrls: { - default: { - http: ["http://localhost:8545/"], - }, - }, - testnet: true, -}; - -// remove chain.localhost or ethermint depending on which you want to connect to -const { chains, provider } = configureChains( - [chain.localhost, ethermint], - [publicProvider()], -); - -const connectors = connectorsForWallets([ - { - groupName: "Recommended", - wallets: [metaMaskWallet({ chains }), injectedWallet({ chains })], - }, -]); - -const wagmiClient = createClient({ - autoConnect: true, - connectors, - provider, -}); - -const containerStyle = { - width: "900px", - margin: "0 auto", -}; - -ReactDOM.createRoot(document.getElementById("root")).render( - - -
- -
- - , -); -``` - -### Creating and reading posts - -Now that the base configuration is set up we’ll create a view that allows -users to create and view posts. - -We’ll be using IPFS to upload the content of the post, then anchoring the hash -of the post on chain. When we retrieve the post, we can then read the value from -IPFS to view the post. - -Update App.jsx with the following code: - - - -```jsx title="frontend/src/App.jsx" -import { useState, useEffect } from "react"; -import { ConnectButton } from "@rainbow-me/rainbowkit"; -import { ethers } from "ethers"; -import { create } from "ipfs-http-client"; -import { Buffer } from "buffer"; -import Blog from "../Blog.json"; -import { useAccount } from "wagmi"; - -/* configure authorization for Infura and IPFS */ -const auth = - "Basic " + - Buffer.from( - import.meta.env.VITE_INFURA_ID + ":" + import.meta.env.VITE_INFURA_SECRET, - ).toString("base64"); - -/* create an IPFS client */ -const client = create({ - host: "ipfs.infura.io", - port: 5001, - protocol: "https", - headers: { - authorization: auth, - }, -}); - -const contractAddress = "your-ethermint-contract-address"; - -function App() { - useEffect(() => { - fetchPosts(); - }, []); - const [viewState, setViewState] = useState("view-posts"); - const [posts, setPosts] = useState([]); - const [title, setTitle] = useState(""); - const [content, setContent] = useState(""); - const { address } = useAccount(); - - /* when the component loads, useEffect will call this function */ - async function fetchPosts() { - const provider = new ethers.providers.Web3Provider(window.ethereum); - const contract = new ethers.Contract(contractAddress, Blog.abi, provider); - let data = await contract.fetchPosts(); - /* once the data is returned from the network we map over it and */ - /* transform the data into a more readable format */ - data = data.map((d) => ({ - content: d["content"], - title: d["title"], - published: d["published"], - id: d["id"].toString(), - })); - - /* we then fetch the post content from IPFS and add it to the post objects */ - data = await Promise.all( - data.map(async (d) => { - const endpoint = `https://infura-ipfs.io/ipfs/${d.content}`; - const options = { - mode: "no-cors", - }; - const response = await fetch(endpoint, options); - const value = await response.text(); - d.postContent = value; - return d; - }), - ); - - setPosts(data); - } - - async function createPost() { - const added = await client.add(content); - const provider = new ethers.providers.Web3Provider(window.ethereum); - const signer = provider.getSigner(); - - const contract = new ethers.Contract(contractAddress, Blog.abi, signer); - const tx = await contract.createPost(title, added.path); - await tx.wait(); - setViewState("view-posts"); - } - - function toggleView(value) { - setViewState(value); - if (value === "view-posts") { - fetchPosts(); - } - } - - return ( -
-
-

Modular Rollup Blog

-

- This allows users to securely create and share blog posts on the - blockchain without the need for a centralized server or authority. -

- {!address ? ( -
-

Getting Started

-

- First, you will need to connect your Ethereum wallet to Ethermint - to display the posts from the smart contract and make posts. -

-
- ) : null} -
-

- Connect your Ethereum wallet to begin ✨ -

-
- -
- {address ? ( -
- - -
- ) : null} - {viewState === "view-posts" && address && ( -
-
-

Posts

- {posts.map((post, index) => ( -
-

{post.title}

- - {/* - {post.postContent} - */} -

GMID: {post.id}

-
- ))} -
-
- )} - {viewState === "create-post" && ( -
-

Create Post

- setTitle(e.target.value)} - style={inputStyle} - /> -