├── .eslintrc.json ├── .github ├── .codespellignore └── workflows │ ├── build.yml │ ├── deploy.yml │ ├── latest_tags.yml │ ├── link-check.yml │ ├── preview.yml │ └── spellcheck.yml ├── .gitignore ├── .husky ├── commit-msg └── pre-commit ├── .markdownlintignore ├── .vitepress ├── components │ ├── ArabicaDevnetDetails.vue │ ├── ArabicaVersionTags.vue │ ├── MainnetBetaDetails.vue │ ├── MainnetVersionTags.vue │ ├── MochaTestnetDetails.vue │ ├── MochaVersionTags.vue │ ├── OrchRelayerVersion.vue │ └── UrlImageButton.vue ├── config.ts ├── constants │ ├── arabica_versions.js │ ├── constants.js │ ├── mainnet_versions.js │ └── mocha_versions.js └── theme │ ├── index.ts │ └── style.css ├── README.md ├── commitlint.config.js ├── community ├── coc.md ├── foundation-delegation-program.md ├── foundation-ecosystem-delegation-program.md ├── modular-meetup-guide.md ├── modular-meetup-intro.md ├── modular-meetup-toolkit.md └── speaker-list.md ├── example_test.go ├── go.mod ├── how-to-guides ├── arabica-devnet.md ├── arbitrum-full-node.md ├── arbitrum-integration.md ├── audits.md ├── blobstream-contracts.md ├── blobstream-offchain.md ├── blobstream-proof-queries.md ├── blobstream-rollups.md ├── blobstream-x-deploy.md ├── blobstream-x-requesting-data-commitment-ranges.md ├── blobstream.md ├── blobstreamx.md ├── bridge-node.md ├── celestia-app-commands.md ├── celestia-app-metrics.md ├── celestia-app-multisig.md ├── celestia-app-slashing.md ├── celestia-app-upgrade-monitor.md ├── celestia-app-vesting.md ├── celestia-app-wallet.md ├── celestia-app.md ├── celestia-node-custom-networks.md ├── celestia-node-metrics.md ├── celestia-node-store-structure.md ├── celestia-node-troubleshooting.md ├── celestia-node-trusted-hash.md ├── celestia-node.md ├── config-toml.md ├── consensus-node.md ├── decide-node.md ├── docker-images.md ├── environment.md ├── feegrant-for-blobs.md ├── full-storage-node.md ├── ibc-relayer.md ├── instantiate-testnet.md ├── intro-to-op-stack.md ├── light-node.md ├── local-devnet.md ├── mainnet.md ├── mammoth.md ├── mocha-testnet.md ├── multiaccounts.md ├── network-upgrade-process.md ├── nitro-local.md ├── nodes-overview.md ├── optimism.md ├── participate.md ├── quick-start.md ├── rollup-stacks.md ├── snapshots.md ├── sp1-blobstream-deploy.md ├── submit-data.md ├── systemd.md ├── transaction-resubmission.md ├── validator-node.md └── zfs.md ├── index.md ├── learn ├── how-celestia-works │ ├── data-availability-faq.md │ ├── data-availability-layer.md │ ├── monolithic-vs-modular.md │ ├── overview.md │ └── transaction-lifecycle.md ├── how-to-stake-tia.md ├── paying-for-blobspace.md ├── retrievability.md ├── staking-governance-supply.md ├── staking.md └── tia.md ├── lychee.toml ├── package.json ├── public ├── Blobspace.png ├── Celestia-og.png ├── Documentation.png ├── audits │ ├── Blobstream_X-Informal_Systems_Audit.pdf │ ├── Blobstream_X-OtterSec_Audit.pdf │ ├── Blobstream_X-Veridise_Audit.pdf │ ├── Blobstream_X-Zellic_Audit.pdf │ ├── Celestia_OP_Stack_Audit.pdf │ ├── SP1_Blobstream_Ottersec_Audit.pdf │ └── celestia_shwap_audit_final.pdf ├── build │ ├── altlayer.webp │ ├── arbitrum.webp │ ├── astria.webp │ ├── caldera.webp │ ├── conduit.webp │ ├── dymension.webp │ ├── gateway.webp │ ├── gelato.webp │ ├── karnot.webp │ ├── lumoz.webp │ ├── opstack.webp │ ├── polygon.webp │ ├── rollkit.webp │ ├── snapchain.webp │ ├── sovereign.webp │ ├── stackr.webp │ ├── vistara.webp │ └── zeeve.webp ├── celestia-app.sh ├── celestia-node.sh ├── favicons │ ├── favicon-dark.ico │ ├── favicon-dark.png │ ├── favicon-dark.svg │ ├── favicon.ico │ ├── favicon.png │ └── favicon.svg ├── fonts │ ├── untitled-sans │ │ ├── untitled-sans-medium.woff2 │ │ └── untitled-sans-regular.woff2 │ └── youth │ │ ├── Youth-Regular.woff │ │ └── Youth-Regular.woff2 ├── grove │ └── grove-sandbox.png ├── img │ ├── Celestia-Arbitrum.png │ ├── Celestia_Bubs_Testnet.jpg │ ├── Celestia_Modular_meetup2.jpg │ ├── Celestia_ethereum-fallback.jpg │ ├── Mainnet-Beta.png │ ├── arabica-devnet.png │ ├── blobstream │ │ ├── Blobstream.png │ │ ├── Celestia_Blobstream_X1b.png │ │ ├── Celestia_Blobstream_X2b.png │ │ ├── Celestia_Blobstream_attestation_flow.jpg │ │ ├── blobstream-commitment-diagram.png │ │ ├── blobstream-orchestrator.png │ │ ├── blobstream-relayer.png │ │ ├── blobstream-square.png │ │ └── blobstream_logo.png │ ├── celestia_mammoths_transparent_bg.png │ ├── cohort-timeline.jpg │ ├── da-and-validity.png │ ├── ecosystem-delegation-program.jpg │ ├── foundation-delegation-program.jpg │ ├── gem.png │ ├── gem │ │ ├── gem1.gif │ │ ├── gem2.gif │ │ ├── gem3.gif │ │ └── gem4.gif │ ├── gm-arb.png │ ├── gm_bubs.png │ ├── gm_contract.png │ ├── keplr.png │ ├── keplr │ │ ├── keplr1.gif │ │ ├── keplr2.gif │ │ ├── keplr3.gif │ │ └── keplr4.gif │ ├── leap.png │ ├── leap │ │ ├── leap1.gif │ │ ├── leap2.gif │ │ └── leap3.gif │ ├── learn │ │ ├── Celestia_TIA_Allocation_at_Genesis.png │ │ ├── Celestia_TIA_Available_Supply.png │ │ ├── Celestia_TIA_Inflation.png │ │ ├── celestia-app.png │ │ ├── consensus-da.png │ │ ├── data-availability-faq │ │ │ ├── Data-availability.png │ │ │ └── Data-storage.png │ │ ├── monolithic-modular.png │ │ ├── nmt.png │ │ ├── reed-solomon-encoding.png │ │ └── tx-lifecycle.png │ ├── mamo-1.png │ ├── mamo │ │ ├── mamo-blob.png │ │ ├── mamo-dbenter.png │ │ ├── mamo-dbstart.png │ │ ├── mamo-nodeinfo.png │ │ ├── mamo-post.png │ │ ├── mamo-retrieve.png │ │ └── mamo-sampler.png │ ├── mocha.jpg │ ├── modular_fellows.jpg │ ├── nitrogen-testnet.jpg │ ├── nodes │ │ ├── BridgeNodes.png │ │ ├── LightNodes.png │ │ ├── consensus-node.jpg │ │ ├── full-storage-node.png │ │ └── validator.png │ └── rollkit.png ├── logo-dark.svg ├── logo-light.svg └── modular.svg ├── tutorials ├── celestia-node-key.md ├── golang-client-tutorial.md ├── integrate-celestia.md ├── node-api.md ├── node-tutorial.md ├── rust-client-tutorial.md └── wallets.md └── yarn.lock /.eslintrc.json: -------------------------------------------------------------------------------- 1 | { 2 | "env": { 3 | "browser": true, 4 | "es2021": true, 5 | "node": true 6 | }, 7 | "extends": [ 8 | "eslint:recommended", 9 | "plugin:@typescript-eslint/recommended", 10 | "plugin:vue/vue3-essential" 11 | ], 12 | "parserOptions": { 13 | "ecmaVersion": "latest", 14 | "parser": "@typescript-eslint/parser", 15 | "sourceType": "module" 16 | }, 17 | "plugins": ["@typescript-eslint", "vue"], 18 | "rules": {} 19 | } 20 | -------------------------------------------------------------------------------- /.github/.codespellignore: -------------------------------------------------------------------------------- 1 | cips 2 | pullrequest 3 | keypair 4 | pastTime 5 | hasTables 6 | Nam 7 | tia 8 | nd 9 | te 10 | Rollup 11 | rollups 12 | rollup 13 | staking 14 | validator 15 | validators 16 | blockchain 17 | chainid 18 | lightnode 19 | fullnode 20 | bridgenode 21 | da 22 | DA 23 | blobstream 24 | Blobstream 25 | SP1 26 | sp1 27 | ZK 28 | zk 29 | zkSync 30 | Celestia 31 | celestia 32 | celestiaorg 33 | Tendermint 34 | tendermint 35 | Cosmos 36 | cosmos 37 | SDK 38 | api 39 | API 40 | JSON 41 | json 42 | RPC 43 | rpc 44 | CLI 45 | cli 46 | gRPC 47 | grpc 48 | ABCI 49 | abci 50 | IBC 51 | ibc 52 | EVM 53 | evm 54 | Ethereum 55 | ethereum 56 | Mainnet 57 | mainnet 58 | Testnet 59 | testnet 60 | Devnet 61 | devnet 62 | Mocha 63 | mocha 64 | Arabica 65 | arabica 66 | blockspace 67 | namespace 68 | namespaces 69 | deployer 70 | deployers 71 | Osmosis 72 | osmosis 73 | Dymension 74 | dymension 75 | Arbitrum 76 | arbitrum 77 | Optimism 78 | optimism 79 | Polygon 80 | polygon 81 | Base 82 | nitro 83 | Nitro 84 | Avail 85 | avail 86 | Eigenlayer 87 | eigenlayer 88 | restaking 89 | cryptographic 90 | secp256k1 91 | ed25519 92 | tm-ed25519 93 | sha256 94 | keccak256 95 | merkle 96 | Merkle 97 | precompile 98 | precompiles 99 | multisig 100 | rollkit 101 | Rollkit 102 | archway 103 | Archway 104 | sommelier 105 | Sommelier 106 | evmos 107 | Evmos 108 | juno 109 | Juno 110 | osmosis 111 | injective 112 | Injective 113 | akash 114 | Akash 115 | quickstart 116 | Quickstart 117 | websocket 118 | Websocket 119 | VitePress 120 | vitepress 121 | npm 122 | yarn 123 | git 124 | Git 125 | GitHub 126 | github 127 | pnpm 128 | localhost 129 | dockerfile 130 | Dockerfile 131 | docker 132 | Docker 133 | kubernetes 134 | Kubernetes 135 | yml 136 | yaml 137 | YAML 138 | toml 139 | TOML 140 | golang 141 | Golang 142 | TypeScript 143 | typescript 144 | JavaScript 145 | javascript 146 | nodejs 147 | Node.js 148 | protobuf 149 | Protobuf 150 | gogo 151 | grpcurl 152 | homebrew 153 | Homebrew 154 | MacOS 155 | macOS 156 | Ubuntu 157 | ubuntu 158 | Linux 159 | linux 160 | WSL 161 | systemd 162 | sudo 163 | curl 164 | wget 165 | unzip 166 | gunzip 167 | gzip 168 | tar 169 | sha256sum 170 | chmod 171 | mkdir 172 | htpasswd 173 | nginx 174 | Nginx 175 | TLS 176 | SSL 177 | ssl 178 | tls 179 | JWT 180 | jwt 181 | OAuth 182 | oauth 183 | CORS 184 | cors 185 | HTTP 186 | http 187 | HTTPS 188 | https 189 | WebSocket 190 | websocket 191 | URI 192 | uri 193 | URL 194 | url 195 | DNS 196 | dns 197 | IP 198 | tcp 199 | TCP 200 | UDP 201 | udp 202 | CIDR 203 | cidr 204 | IPv4 205 | ipv4 206 | IPv6 207 | ipv6 208 | ascii 209 | ASCII 210 | UTF-8 211 | utf-8 212 | base64 213 | Base64 214 | hex 215 | hexadecimal 216 | binary 217 | octal 218 | uint64 219 | uint32 220 | int64 221 | int32 222 | bool 223 | boolean 224 | struct 225 | enum 226 | proto 227 | Proto 228 | gRPC-gateway 229 | grpc-gateway 230 | OpenAPI 231 | openapi 232 | Swagger 233 | swagger 234 | REST 235 | rest 236 | GraphQL 237 | graphql 238 | SQL 239 | sql 240 | NoSQL 241 | nosql 242 | PostgreSQL 243 | postgresql 244 | MySQL 245 | mysql 246 | SQLite 247 | sqlite 248 | MongoDB 249 | mongodb 250 | Redis 251 | redis 252 | Kafka 253 | kafka 254 | RabbitMQ 255 | rabbitmq 256 | NATS 257 | nats 258 | etcd 259 | Etcd 260 | Consul 261 | consul 262 | Vault 263 | vault 264 | Terraform 265 | terraform 266 | Ansible 267 | ansible 268 | Kubernetes 269 | kubernetes 270 | kubectl 271 | helm 272 | Helm 273 | Istio 274 | istio 275 | Prometheus 276 | prometheus 277 | Grafana 278 | grafana 279 | Jaeger 280 | jaeger 281 | Zipkin 282 | zipkin 283 | fluentd 284 | Fluentd 285 | logstash 286 | Logstash 287 | Elasticsearch 288 | elasticsearch 289 | Kibana 290 | kibana 291 | Filebeat 292 | filebeat 293 | Metricbeat 294 | metricbeat 295 | crate 296 | crates 297 | optimized 298 | optimize 299 | categorize 300 | categories 301 | centralized 302 | centralize 303 | finalized 304 | finalize 305 | initialized 306 | initialize 307 | parallelized 308 | parallelize -------------------------------------------------------------------------------- /.github/workflows/build.yml: -------------------------------------------------------------------------------- 1 | name: Build VitePress Site 2 | 3 | on: 4 | push: 5 | branches: [main] 6 | pull_request: 7 | 8 | jobs: 9 | build: 10 | runs-on: ubuntu-latest 11 | steps: 12 | - name: Checkout 13 | uses: actions/checkout@v4 14 | - name: Setup Node 15 | uses: actions/setup-node@v4 16 | with: 17 | node-version: 18 18 | cache: yarn # or pnpm / npm 19 | - name: Install dependencies 20 | run: yarn install # or pnpm install / npm ci 21 | - name: Lint JavaScript/TypeScript 22 | run: yarn eslint 23 | - name: Check formatting 24 | run: yarn prettier --check '**/*.{js,jsx,ts,tsx,md,json,css,scss}' 25 | - name: Lint Markdown 26 | run: yarn lint:md 27 | continue-on-error: true 28 | - name: Build with VitePress 29 | run: yarn build # or pnpm build / npm run build 30 | - name: Setup Go 31 | uses: actions/setup-go@v5 32 | with: 33 | go-version: '1.23' 34 | cache-dependency-path: go.sum 35 | - name: Test Go tutorial examples compilation 36 | run: | 37 | echo "Testing Go tutorial examples compilation..." 38 | # Test syntax and type checking without building 39 | go mod tidy 40 | # Run syntax check 41 | gofmt -l example_test.go 42 | # Test compilation (may timeout but will catch syntax errors) 43 | timeout 300s go build example_test.go || echo "Note: Build may timeout due to dependencies, but syntax was validated" 44 | echo "Go compilation test passed!" 45 | -------------------------------------------------------------------------------- /.github/workflows/deploy.yml: -------------------------------------------------------------------------------- 1 | # Sample workflow for building and deploying a VitePress site to GitHub Pages 2 | # 3 | name: Deploy VitePress site to Pages 4 | 5 | on: 6 | # Runs on pushes targeting the `main` branch. Change this to `master` if you're 7 | # using the `master` branch as the default branch. 8 | push: 9 | branches: [main] 10 | 11 | # Allows you to run this workflow manually from the Actions tab 12 | workflow_dispatch: 13 | 14 | # Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages 15 | permissions: write-all 16 | 17 | # Allow only one concurrent deployment, skipping runs queued between the run in-progress and latest queued. 18 | # However, do NOT cancel in-progress runs as we want to allow these production deployments to complete. 19 | concurrency: 20 | group: pages 21 | cancel-in-progress: false 22 | 23 | jobs: 24 | # Build job 25 | build: 26 | runs-on: ubuntu-latest 27 | steps: 28 | - name: Checkout 29 | uses: actions/checkout@v4 30 | with: 31 | fetch-depth: 0 # Not needed if lastUpdated is not enabled 32 | # - uses: pnpm/action-setup@v2 # Uncomment this if you're using pnpm 33 | - name: Setup Node 34 | uses: actions/setup-node@v3 35 | with: 36 | node-version: 18 37 | cache: yarn # or pnpm / npm 38 | - name: Setup Pages 39 | uses: actions/configure-pages@v3 40 | - name: Install dependencies 41 | run: yarn install # or pnpm install / npm ci 42 | - name: Build with VitePress 43 | run: yarn build # or pnpm docs:build / npm docs:build 44 | - name: Deploy to GitHub Pages 45 | uses: peaceiris/actions-gh-pages@v3 46 | with: 47 | github_token: ${{ secrets.GITHUB_TOKEN }} 48 | publish_dir: ./.vitepress/dist 49 | force_orphan: true 50 | # The following lines assign commit authorship to the official 51 | # GH-Actions bot for deploys to `gh-pages` branch: 52 | # https://github.com/actions/checkout/issues/13#issuecomment-724415212 53 | # The GH actions bot is used by default if you didn't specify the two fields. 54 | # You can swap them out with your own user credentials. 55 | cname: docs.celestia.org 56 | user_name: jcstein 57 | user_email: joshcs@celestia.org 58 | -------------------------------------------------------------------------------- /.github/workflows/latest_tags.yml: -------------------------------------------------------------------------------- 1 | name: Latest Tags 2 | 3 | on: 4 | workflow_dispatch: 5 | # Inputs the workflow accepts. These are the options visible when manually 6 | # triggering the workflow 7 | inputs: 8 | # `network` is the name of the input and is customizable. We can name it 9 | # whatever we want. Just note that if we change the name here we will need 10 | # to change the name where it is referenced 11 | network: 12 | # Friendly description to be shown in the UI instead of 'network' 13 | description: "Which network are we updating the latest tag information?" 14 | # Input has to be provided for the workflow to run 15 | required: true 16 | type: choice 17 | # These are the drop down options, so we can add other networks, like 18 | # mainnet for instance. 19 | options: 20 | - mainnet 21 | - arabica 22 | - mocha 23 | 24 | jobs: 25 | # This job pulls the latest tag information for the repos listed in the matrix 26 | # strategy 27 | logLatestRelease: 28 | runs-on: ubuntu-latest 29 | strategy: 30 | matrix: 31 | # If we want more repos, we can just add them here. 32 | repo: [celestia-app, celestia-node] 33 | env: 34 | # This workflow is set for the celestiaorg github org, if we need other 35 | # orgs we will need to restructure this workflow 36 | owner: celestiaorg 37 | # Define the outputs for other steps to access 38 | outputs: 39 | celestia-app_latest_tag: ${{ steps.set_outputs.outputs.celestia-app_latest_tag }} 40 | celestia-app_latest_sha: ${{ steps.set_outputs.outputs.celestia-app_latest_sha }} 41 | celestia-node_latest_tag: ${{ steps.set_outputs.outputs.celestia-node_latest_tag }} 42 | celestia-node_latest_sha: ${{ steps.set_outputs.outputs.celestia-node_latest_sha }} 43 | steps: 44 | - name: Log target owner/repo 45 | run: "echo Pulling info from: '${{ env.owner }}/${{ matrix.repo }}'" 46 | 47 | - name: Query /releases endpoint 48 | uses: octokit/request-action@v2.x 49 | id: get_latest_release 50 | with: 51 | route: GET /repos/{owner}/{repo}/releases 52 | owner: ${{ env.owner }} 53 | repo: ${{ matrix.repo }} 54 | env: 55 | GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} 56 | 57 | - name: Log latest tag 58 | run: "echo latest tag: '${{ fromJSON(steps.get_latest_release.outputs.data)[0].tag_name }}'" 59 | 60 | - name: Query /git/ref/tag endpoint 61 | uses: octokit/request-action@v2.x 62 | id: get_latest_commit 63 | with: 64 | route: GET /repos/{owner}/{repo}/git/ref/tags/${{ fromJSON(steps.get_latest_release.outputs.data)[0].tag_name }} 65 | owner: ${{ env.owner }} 66 | repo: ${{ matrix.repo }} 67 | env: 68 | GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} 69 | 70 | - name: Log latest sha 71 | run: "echo latest commit: '${{ fromJSON(steps.get_latest_commit.outputs.data).object.sha }}'" 72 | 73 | - name: Set outputs 74 | id: set_outputs 75 | run: | 76 | echo "${{matrix.repo}}_latest_tag=${{ fromJSON(steps.get_latest_release.outputs.data)[0].tag_name }}" >> $GITHUB_OUTPUT 77 | echo "${{matrix.repo}}_latest_sha=${{ fromJSON(steps.get_latest_commit.outputs.data).object.sha }}" >> $GITHUB_OUTPUT 78 | 79 | # This job creates a PR if there were changes. The changes are created when 80 | # the workflow writes to the version files. This means that the workflow 81 | # should be able to be run and will just be a no-op if the is no new release. 82 | # Either way, since a PR is created, this job won't break the docs on main. 83 | createPR: 84 | needs: logLatestRelease 85 | runs-on: ubuntu-latest 86 | permissions: 87 | contents: write 88 | pull-requests: write 89 | steps: 90 | - uses: actions/checkout@v4 91 | - name: Write latest tags and commit SHAs to txt files 92 | # This is the code that writes to a file. If we need to update the file 93 | # layout, contents, or file name, do it here. 94 | run: | 95 | CONTENTS=$(cat << EOF 96 | const ${{ inputs.network }}Versions = Object.freeze({ 97 | "app-latest-tag": "${{ needs.logLatestRelease.outputs.celestia-app_latest_tag }}", 98 | "app-latest-sha": "${{ needs.logLatestRelease.outputs.celestia-app_latest_sha }}", 99 | "node-latest-tag": "${{ needs.logLatestRelease.outputs.celestia-node_latest_tag }}", 100 | "node-latest-sha": "${{ needs.logLatestRelease.outputs.celestia-node_latest_sha }}" 101 | }); 102 | export default ${{ inputs.network }}Versions; 103 | EOF 104 | ) 105 | echo $CONTENTS > .vitepress/constants/\${{ inputs.network }}_versions.js 106 | - name: Install Prettier 107 | run: | 108 | npm install -g prettier 109 | - name: Format the code with Prettier 110 | run: | 111 | prettier .vitepress/constants/\${{ inputs.network }}_versions.js --write 112 | - name: Open PR 113 | uses: peter-evans/create-pull-request@v4 114 | with: 115 | # This github action has a lot of options, currently we just tweak the 116 | # commit-message and title of the PR. 117 | commit-message: "[automated GH action] update latest release tags & commit sha (${{ inputs.network }})" 118 | title: "[GH Action] Update release tags and commit SHAs for ${{ inputs.network }}" 119 | token: ${{ secrets.PAT_CREATE_PR }} 120 | -------------------------------------------------------------------------------- /.github/workflows/link-check.yml: -------------------------------------------------------------------------------- 1 | name: Link Checker 2 | 3 | permissions: 4 | contents: read 5 | 6 | on: 7 | push: 8 | branches: [main] 9 | pull_request: 10 | schedule: 11 | # Run weekly on Monday at 9 AM UTC 12 | - cron: '0 9 * * 1' 13 | 14 | jobs: 15 | link-check: 16 | runs-on: ubuntu-latest 17 | steps: 18 | - name: Checkout 19 | uses: actions/checkout@v4 20 | 21 | - name: Link Checker 22 | uses: lycheeverse/lychee-action@v2 23 | with: 24 | # Fail action on broken links 25 | fail: true 26 | # Use the lychee.toml config file 27 | args: --config lychee.toml --verbose '**/*.md' '.vitepress/config.ts' 28 | # Optional: set a token for GitHub API access to avoid rate limiting 29 | token: ${{ secrets.GITHUB_TOKEN }} -------------------------------------------------------------------------------- /.github/workflows/preview.yml: -------------------------------------------------------------------------------- 1 | name: Deploy PR previews 2 | 3 | on: 4 | pull_request: 5 | types: 6 | - opened 7 | - reopened 8 | - synchronize 9 | - closed 10 | 11 | concurrency: preview-${{ github.ref }} 12 | 13 | jobs: 14 | deploy-preview: 15 | runs-on: ubuntu-latest 16 | permissions: write-all 17 | steps: 18 | - name: Checkout 19 | uses: actions/checkout@v4 20 | 21 | - name: Setup Node 22 | uses: actions/setup-node@v3 23 | with: 24 | node-version: 18 25 | cache: yarn 26 | 27 | - name: Install dependencies 28 | run: yarn install --frozen-lockfile 29 | 30 | - name: Build with Base URL 31 | run: BASE='/docs-preview/pr-${{ github.event.number }}/' yarn build 32 | 33 | - name: Deploy preview 34 | uses: rossjrw/pr-preview-action@v1 35 | with: 36 | source-dir: .vitepress/dist 37 | deploy-repository: celestiaorg/docs-preview 38 | token: ${{ secrets.PREVIEW_DEPLOY }} 39 | preview-branch: main 40 | umbrella-dir: . 41 | -------------------------------------------------------------------------------- /.github/workflows/spellcheck.yml: -------------------------------------------------------------------------------- 1 | name: Spellcheck 2 | 3 | on: 4 | push: 5 | branches: [main] 6 | pull_request: 7 | 8 | permissions: 9 | contents: read 10 | pull-requests: write 11 | 12 | jobs: 13 | spellcheck: 14 | runs-on: ubuntu-latest 15 | steps: 16 | - name: Checkout 17 | uses: actions/checkout@v4 18 | with: 19 | # This ensures that the workflow can access the entire git history 20 | # if needed for creating pull requests 21 | token: ${{ secrets.GITHUB_TOKEN }} 22 | - name: Install codespell 23 | run: | 24 | sudo apt-get update 25 | sudo apt-get install codespell -y 26 | - name: Run codespell 27 | continue-on-error: true 28 | run: | 29 | codespell -w --skip="*.git,*.js,*.json,*.lock,*.css,*.scss,*.svg,*.png,*.jpg,*.jpeg,*.gif,*.ico,*.woff,*.woff2,*.ttf,*.eot,node_modules,public,dist,.vitepress/dist,.vitepress/cache,yarn.lock" --ignore-words=.github/.codespellignore 30 | - name: Check for changes 31 | id: verify-changed-files 32 | run: | 33 | if [ -n "$(git status --porcelain)" ]; then 34 | echo "changed=true" >> $GITHUB_OUTPUT 35 | echo "Files with spelling corrections:" 36 | git status --porcelain 37 | else 38 | echo "changed=false" >> $GITHUB_OUTPUT 39 | echo "No spelling errors found." 40 | fi 41 | - name: Create Pull Request 42 | if: steps.verify-changed-files.outputs.changed == 'true' && github.event_name == 'push' && github.ref == 'refs/heads/main' 43 | uses: peter-evans/create-pull-request@v5 44 | with: 45 | token: ${{ secrets.GITHUB_TOKEN }} 46 | commit-message: "fix: correct spelling errors" 47 | title: "fix: correct spelling errors" 48 | body: | 49 | This PR fixes spelling errors found by codespell. 50 | 51 | Auto-generated by the spellcheck workflow. 52 | branch: fix/spelling-corrections 53 | delete-branch: true -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | .vitepress/dist 2 | node_modules 3 | package-lock.json 4 | .vitepress/cache/** 5 | *.log 6 | *.tgz 7 | .DS_Store 8 | .idea 9 | .temp 10 | .vite_opt_cache 11 | .vscode 12 | .lycheecache 13 | 14 | # Go build artifacts 15 | go.sum 16 | example_test 17 | -------------------------------------------------------------------------------- /.husky/commit-msg: -------------------------------------------------------------------------------- 1 | #!/bin/sh 2 | . "$(dirname "$0")/_/husky.sh" 3 | 4 | npx commitlint --edit $1 -------------------------------------------------------------------------------- /.husky/pre-commit: -------------------------------------------------------------------------------- 1 | #!/usr/bin/env sh 2 | . "$(dirname -- "$0")/_/husky.sh" 3 | 4 | npx lint-staged 5 | -------------------------------------------------------------------------------- /.markdownlintignore: -------------------------------------------------------------------------------- 1 | node_modules/ -------------------------------------------------------------------------------- /.vitepress/components/ArabicaDevnetDetails.vue: -------------------------------------------------------------------------------- 1 | 47 | 48 | -------------------------------------------------------------------------------- /.vitepress/components/ArabicaVersionTags.vue: -------------------------------------------------------------------------------- 1 | 33 | 34 | -------------------------------------------------------------------------------- /.vitepress/components/MainnetBetaDetails.vue: -------------------------------------------------------------------------------- 1 | 47 | 48 | -------------------------------------------------------------------------------- /.vitepress/components/MainnetVersionTags.vue: -------------------------------------------------------------------------------- 1 | 33 | 34 | -------------------------------------------------------------------------------- /.vitepress/components/MochaTestnetDetails.vue: -------------------------------------------------------------------------------- 1 | 47 | 48 | -------------------------------------------------------------------------------- /.vitepress/components/MochaVersionTags.vue: -------------------------------------------------------------------------------- 1 | 33 | 34 | -------------------------------------------------------------------------------- /.vitepress/components/OrchRelayerVersion.vue: -------------------------------------------------------------------------------- 1 | 10 | 11 | -------------------------------------------------------------------------------- /.vitepress/components/UrlImageButton.vue: -------------------------------------------------------------------------------- 1 | 10 | 11 | 25 | 26 | 101 | -------------------------------------------------------------------------------- /.vitepress/constants/arabica_versions.js: -------------------------------------------------------------------------------- 1 | const arabicaVersions = Object.freeze({ 2 | "app-latest-tag": "v4.0.2-arabica", 3 | "app-latest-sha": "4fc26c1e3f1aa590da31f8f8c8400357807f6556", 4 | "node-latest-tag": "v0.23.0-arabica", 5 | "node-latest-sha": "b814f44afb5bde01b3714c4f21fe34203d90405d", 6 | }); 7 | export default arabicaVersions; 8 | -------------------------------------------------------------------------------- /.vitepress/constants/constants.js: -------------------------------------------------------------------------------- 1 | const constants = Object.freeze({ 2 | golangNodeMainnet: "1.23.0", 3 | golangNodeMocha: "1.24.1", 4 | golangNodeArabica: "1.23.2", 5 | golangApp: "1.22.6", 6 | golangCore: "1.22.6", 7 | golang: "1.22.0", 8 | arabicaChainId: "arabica-11", 9 | mainnetChainId: "celestia", 10 | mochaChainId: "mocha-4", 11 | arabicaRollkitVersion: "v0.10.5", 12 | mochaRollkitVersion: "v0.10.5", 13 | mainnetRollkitVersion: "v0.10.5", 14 | localCelestiaDevnetVersion: "v0.8.2", 15 | golangBlobstream: "1.21.4", 16 | orchrelayVersion: "v1.0.1", 17 | mochaRpcUrl: "https://rpc-mocha.pops.one/", 18 | mochaRestUrl: "https://api-mocha.pops.one/", 19 | arabicaRpcUrl: "https://rpc.celestia-arabica-11.com/", 20 | arabicaRestUrl: "https://api.celestia-arabica-11.com", 21 | mainnetRpcUrl: "https://rpc.lunaroasis.net/", 22 | mainnetRestUrl: "https://api.lunaroasis.net/", 23 | }); 24 | export default constants; 25 | -------------------------------------------------------------------------------- /.vitepress/constants/mainnet_versions.js: -------------------------------------------------------------------------------- 1 | const mainnetVersions = Object.freeze({ 2 | "app-latest-tag": "v3.8.1", 3 | "app-latest-sha": "a91f373fba51476c72982618108c7b8a1126c757", 4 | "node-latest-tag": "v0.22.2", 5 | "node-latest-sha": "5dc98d8b249bdb9f9c56d255ce233ecb1c713cfd", 6 | }); 7 | export default mainnetVersions; 8 | -------------------------------------------------------------------------------- /.vitepress/constants/mocha_versions.js: -------------------------------------------------------------------------------- 1 | const mochaVersions = Object.freeze({ 2 | "app-latest-tag": "v4.0.2-mocha", 3 | "app-latest-sha": "3ebd4caecfb0e11e665bb728e50b7812da4dbed1", 4 | "node-latest-tag": "v0.23.1-mocha", 5 | "node-latest-sha": "500bf455aba081561ecccf536d7b49f3a6f224b9", 6 | }); 7 | export default mochaVersions; 8 | -------------------------------------------------------------------------------- /.vitepress/theme/index.ts: -------------------------------------------------------------------------------- 1 | // https://vitepress.dev/guide/custom-theme 2 | import { h } from "vue"; 3 | import Theme from "vitepress/theme"; 4 | import "./style.css"; 5 | 6 | export default { 7 | extends: Theme, 8 | Layout: () => { 9 | return h(Theme.Layout, null, { 10 | // https://vitepress.dev/guide/extending-default-theme#layout-slots 11 | }); 12 | }, 13 | enhanceApp({ app, router, siteData }) { 14 | // ... 15 | }, 16 | }; 17 | -------------------------------------------------------------------------------- /.vitepress/theme/style.css: -------------------------------------------------------------------------------- 1 | /** 2 | * Customize default theme styling by overriding CSS variables: 3 | * https://github.com/vuejs/vitepress/blob/main/src/client/theme-default/styles/vars.css 4 | */ 5 | 6 | /** 7 | * Colors 8 | * -------------------------------------------------------------------------- */ 9 | 10 | :root { 11 | --vp-c-brand: #7b2bf9; 12 | --vp-c-brand-light: #9350fa; 13 | --vp-c-brand-lighter: #a970fb; 14 | --vp-c-brand-lightest: #bf90fc; 15 | --vp-c-brand-dark: #6902e0; 16 | --vp-c-brand-darker: #5801c9; 17 | --vp-c-brand-dimm: rgba(123, 43, 249, 0.08); 18 | } 19 | 20 | /** 21 | * Component: Button 22 | * -------------------------------------------------------------------------- */ 23 | 24 | :root { 25 | --vp-button-brand-border: var(--vp-c-brand-light); 26 | --vp-button-brand-text: var(--vp-c-white); 27 | --vp-button-brand-bg: var(--vp-c-brand); 28 | --vp-button-brand-hover-border: var(--vp-c-brand-light); 29 | --vp-button-brand-hover-text: var(--vp-c-white); 30 | --vp-button-brand-hover-bg: var(--vp-c-brand-light); 31 | --vp-button-brand-active-border: var(--vp-c-brand-light); 32 | --vp-button-brand-active-text: var(--vp-c-white); 33 | --vp-button-brand-active-bg: var(--vp-button-brand-bg); 34 | } 35 | 36 | /** 37 | * Component: Home 38 | * -------------------------------------------------------------------------- */ 39 | 40 | :root { 41 | --vp-home-hero-name-color: transparent; 42 | --vp-home-hero-name-background: -webkit-linear-gradient( 43 | 120deg, 44 | #7b2bf9 30%, 45 | #fd63d9 46 | ); 47 | 48 | --vp-home-hero-image-background-image: linear-gradient( 49 | -45deg, 50 | #7b2bf9 50%, 51 | #fd63d9 50% 52 | ); 53 | --vp-home-hero-image-filter: blur(40px); 54 | } 55 | 56 | @media (min-width: 640px) { 57 | :root { 58 | --vp-home-hero-image-filter: blur(56px); 59 | } 60 | } 61 | 62 | @media (min-width: 960px) { 63 | :root { 64 | --vp-home-hero-image-filter: blur(72px); 65 | } 66 | } 67 | 68 | /** 69 | * Component: Custom Block 70 | * -------------------------------------------------------------------------- */ 71 | 72 | :root { 73 | --vp-custom-block-tip-border: var(--vp-c-brand); 74 | --vp-custom-block-tip-text: var(--vp-c-brand-darker); 75 | --vp-custom-block-tip-bg: var(--vp-c-brand-dimm); 76 | --tab-text-color: #000; 77 | } 78 | 79 | .dark { 80 | --vp-custom-block-tip-border: var(--vp-c-brand); 81 | --vp-custom-block-tip-text: var(--vp-c-brand-lightest); 82 | --vp-custom-block-tip-bg: var(--vp-c-brand-dimm); 83 | --tab-text-color: #fff; 84 | } 85 | 86 | /** 87 | * Component: Algolia 88 | * -------------------------------------------------------------------------- */ 89 | 90 | .DocSearch { 91 | --docsearch-primary-color: var(--vp-c-brand) !important; 92 | } 93 | 94 | @font-face { 95 | font-family: "Untitled-Sans"; 96 | src: url("/fonts/untitled-sans/untitled-sans-regular.woff2") format("woff2"); 97 | font-weight: normal; 98 | font-style: normal; 99 | font-display: swap; 100 | } 101 | 102 | @font-face { 103 | font-family: "Untitled-Sans"; 104 | src: url("/fonts/untitled-sans/untitled-sans-medium.woff2") format("woff2"); 105 | font-weight: 500; 106 | font-style: normal; 107 | font-display: swap; 108 | } 109 | 110 | @font-face { 111 | font-family: "Youth"; 112 | src: url("/fonts/youth/Youth-Regular.woff2") format("woff2"); 113 | font-weight: normal; 114 | font-style: normal; 115 | font-display: swap; 116 | } 117 | 118 | :root { 119 | --font-primary: "Youth", sans-serif; 120 | --font-body: "Untitled-Sans", sans-serif; 121 | } 122 | 123 | h1, 124 | h2, 125 | h3, 126 | h4, 127 | h5, 128 | h6 { 129 | font-family: var(--font-primary); 130 | } 131 | 132 | .youtube-wrapper { 133 | position: relative; 134 | overflow: hidden; 135 | width: 100%; 136 | padding-top: 56.25%; 137 | } 138 | 139 | .youtube-video { 140 | position: absolute; 141 | top: 0; 142 | left: 0; 143 | bottom: 0; 144 | right: 0; 145 | width: 100%; 146 | height: 100%; 147 | border: none; 148 | } 149 | 150 | body { 151 | font-family: var(--font-body); 152 | } 153 | 154 | .VPDoc { 155 | font-family: var(--font-body); 156 | } 157 | 158 | .VPHome { 159 | font-family: var(--font-body); 160 | } 161 | 162 | .VPSidebar { 163 | font-family: var(--font-body) !important; 164 | } 165 | 166 | .VPSidebarItem .text, 167 | .VPSidebarGroup .title, 168 | .VPSidebarGroup .items, 169 | .VPSidebarGroup .VPLink, 170 | .VPDocAsideOutline .outline-title, 171 | .VPDocAsideOutline .outline-link { 172 | font-family: var(--font-body) !important; 173 | font-weight: 400 !important; 174 | } 175 | 176 | .VPSidebarItem.is-active .text { 177 | color: var(--vp-c-brand); 178 | } 179 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | [![CodeQL](https://github.com/celestiaorg/docs/actions/workflows/github-code-scanning/codeql/badge.svg)](https://github.com/celestiaorg/docs/actions/workflows/github-code-scanning/codeql) 2 | [![Build](https://github.com/celestiaorg/docs/actions/workflows/build.yml/badge.svg)](https://github.com/celestiaorg/docs/actions/workflows/build.yml) 3 | [![Deploy](https://github.com/celestiaorg/docs/actions/workflows/deploy.yml/badge.svg)](https://github.com/celestiaorg/docs/actions/workflows/deploy.yml) 4 | [![Twitter](https://img.shields.io/twitter/follow/celestia)](https://x.com/celestia) 5 | [![Discord](https://img.shields.io/discord/638338779505229824)](https://discord.com/invite/celestiacommunity) 6 | [![License](https://img.shields.io/badge/License-Apache2.0-green.svg)](https://www.apache.org/licenses/LICENSE-2.0) 7 | 8 | # Celestia Documentation Site 9 | 10 | Welcome to the official documentation repository for [Celestia](https://celestia.org/). 11 | 12 | Here you'll find comprehensive guides, tutorials, and reference materials 13 | to help you make the most out of Celestia. 14 | 15 | ## Building the site 16 | 17 | To get started, clone the repository and run the following: 18 | 19 | ```bash 20 | yarn && yarn dev 21 | ``` 22 | 23 | This documentation site is built with [VitePress](https://vitepress.dev) 24 | 25 | ## Link checking 26 | 27 | To check for broken links in the documentation, run: 28 | 29 | ```bash 30 | yarn link-check 31 | ``` 32 | 33 | This uses [lychee](https://lychee.cli.rs/) to validate all internal and external links. 34 | The link checker is also run automatically in CI on every push and pull request. 35 | 36 | ## Contribution Guidelines 37 | 38 | We love contributions from the community! Whether you're fixing typos, 39 | improving content clarity, or adding new topics, every contribution helps. 40 | 41 | - Fork & clone: Fork this repository and clone it to your local machine. 42 | - Branch: Always create a new branch for your changes. Naming it relevantly. 43 | - Commit Changes: Make your changes and commit them with a clear and concise 44 | commit message. 45 | - Push & Create PR: Push your changes to your fork and create a pull request 46 | to the main branch of this repository. 47 | 48 | Please ensure to review the detailed Contribution Guidelines above before 49 | making a pull request. 50 | 51 | ### Link Format Guidelines 52 | 53 | When adding internal links to documentation, please use the following format: 54 | `[link text](/base-working-dir/subdir/page.md#section-id)`, i.e. `[link text](/how-to-guides/quick-start.md#get-your-auth-token)` 55 | 56 | This format ensures long-term compatibility and consistent behavior across different platforms and documentation builds. 57 | 58 | ## Directory Structure 59 | 60 | - /learn: A category for learning about Celestia. 61 | - /how-to guides: A category with guides for running a node, deploying 62 | rollups, and building on Celestia. 63 | - /tutorials: A category with tutorials on interacting with celestia-node. 64 | 65 | - /community: A category for the Celestia community. 66 | - /public: Images, diagrams, and other media files used in the documentation. 67 | 68 | ## Feedback & Suggestions 69 | 70 | We value feedback from the community. If you have suggestions for improvements 71 | or find any discrepancies in the documentation, please raise an issue in this 72 | repository. 73 | -------------------------------------------------------------------------------- /commitlint.config.js: -------------------------------------------------------------------------------- 1 | module.exports = { 2 | extends: ["@commitlint/config-conventional"], 3 | env: { 4 | node: true, 5 | }, 6 | }; 7 | -------------------------------------------------------------------------------- /community/modular-meetup-intro.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: The ultimate guide for Modular Meetup organizers! 3 | --- 4 | 5 | # Celestia Modular Meetup program 6 | 7 | ![Modular Meetup Banner](/img/Celestia_Modular_meetup2.jpg) 8 | 9 | Welcome to the ultimate guide for Modular Meetup organizers! 10 | This collection of resources is designed for those enthusiastic 11 | about fostering grassroots Modular Meetups with support from 12 | Celestia around the world. 13 | 14 | ## Program description 15 | 16 | The Celestia Modular Meetup Program aims to empower meetup 17 | organizers, providing education and support, and encouraging 18 | collaboration within the Web3 ecosystem. This rapidly growing 19 | community has already achieved incredible success with the 20 | first Modular Meetup in Lisbon, and will grow from there. 21 | 22 | Join fellow enthusiasts, engage in enlightening discussions, 23 | and make the most of the insightful resources provided. These 24 | resources are designed to serve as a go-to playbook for meetup 25 | organizers, especially when starting your journey. 26 | 27 | ## Important info 28 | 29 | ### Celestia.org Community Code of Conduct 30 | 31 | The purpose of our Community Code of Conduct is to foster an 32 | inclusive, welcoming, and supportive environment for everyone 33 | participating in Celestia community events. We're all here to 34 | learn from each other, expand our skillsets, and enjoy a positive 35 | experience together. 36 | 37 | All meetup attendees, speakers, sponsors, and volunteers, including 38 | the event organizing team, are kindly asked to adhere to the following 39 | Code of Conduct. Organizers will respectfully enforce this code 40 | throughout the event. We genuinely appreciate the cooperation of all 41 | participants in maintaining a safe and empowering space for everyone. 42 | 43 | - [Celestia.org Community Code of Conduct](/community/coc.md) 44 | 45 | ### Signup form 46 | 47 | To become part of the program, please 48 | [complete the registration form](https://docs.google.com/forms/d/1ImYv2sOScgOb0GtWwXSv-ge8uVgO7aFYK42xutJcVtA/edit?usp=sharing_eil_m&ts=6572b6a4). 49 | 50 | Following the review and approval of your submission, you will receive 51 | an email confirmation and an invitation to participate in the upcoming 52 | Modular Meetup call. Furthermore, you will be granted access to the 53 | exclusive Discord channel labeled "#modular-meetup" on our Discord server. 54 | Please take note that [joining our Discord](https://discord.com/invite/YsnTPcSfWQ/) 55 | is a prerequisite for channel access. It's essential to recognize that 56 | this program is tailored for dedicated organizers with a genuine interest 57 | in nurturing their local modular ecosystem community. 58 | 59 | ### Emails 60 | 61 | As a participant in the Celestia Modular Meetup Program, you 62 | can expect to receive the following emails: 63 | 64 | 1. Welcome email with links to calendar events and Discord channel 65 | 2. Monthly Catch-up call invites 66 | 3. Recap emails with notes from calls 67 | 68 | ### Discord 69 | 70 | Your active participation is key to unlocking the full potential 71 | of this vibrant community. Our primary communication tool is Discord, 72 | providing an engaging platform to connect with fellow organizers: 73 | 74 | - [Discord](https://discord.com/invite/je7UVpDuDu) 75 | 76 | ### Materials 77 | 78 | As a meetup organizer, you'll gain access to the Celestia Modular Meetup 79 | Program's list of resources. This collection should become your trusted 80 | companion in organizing events. Drawing upon the wisdom of seasoned event 81 | organizers, this resource is available for you and your co-organizers 82 | to explore and learn. 83 | 84 | - [Meetup Guide](/community/modular-meetup-guide.md) 85 | - [Modular Meetup Toolkit](/community/modular-meetup-toolkit.md) 86 | - [Speaker List](/community/speaker-list.md) 87 | -------------------------------------------------------------------------------- /community/modular-meetup-toolkit.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: A toolkit for Modular Meetups. 3 | --- 4 | 5 | # Modular Meetup Toolkit 6 | 7 | Welcome to the Modular Meetups Toolkit! This kit is designed 8 | to help you run successful meetups for the Celestia community. 9 | As the first modular blockchain, Celestia offers a lot to discuss 10 | and explore. This kit includes useful resources and materials to 11 | help you plan and execute your meetups effectively. 12 | 13 | ## Celestia branding guidelines 14 | 15 | - [Brand kit](https://company-223625.frontify.com/d/JoSwaZS4Mjpj/guidelines) 16 | 1. Includes logo files, color schemes, typography, icons and illustrations 17 | 18 | ## Sample “Introduction to Modularity” workshop presentation 19 | 20 | - [Sample presentation - introduction to modularity](https://docs.google.com/presentation/d/1R4bkWgU2nql1chwVwND4seREHbKzugl0-Xr88w3QdIQ/edit#slide=id.g1b629412475_0_0) 21 | - Summary: This is an overview presentation on Modular blockchains and 22 | dives deep into Celestia core technologies. 23 | - The sample presentation covers: 24 | 1. What are modular blockchains? 25 | 2. The benefits of modular over monolithic blockchains 26 | 3. Introduction to Celestia: The first modular blockchain 27 | 4. The concept of Data Availability Sampling 28 | 5. Sovereign Rollups 29 | 6. Q&A session 30 | 31 | ## Sample “Run a Celestia light node” workshop presentation 32 | 33 | - [Sample presentation - run a light node](https://docs.google.com/presentation/d/1fV7OYUdW4kafkZcgHwFenFWDbSIwkk0R6BnSKrAV-Hc/edit#slide=id.g20713cce7c2_1_0) 34 | - Summary: 35 | This is an overview presentation that goes over running a Celestia light node. 36 | You can find existing video presentations for this here: 37 | - The sample presentation covers: 38 | 1. What is a Celestia light node? 39 | 2. The role of light nodes in the Celestia ecosystem 40 | 3. Setting up a light node: hardware and software requirements 41 | 4. Step-by-step guide on how to run a Celestia light node 42 | 5. Troubleshooting common issues 43 | 6. Best practices for maintaining a light node 44 | 7. Q&A session 45 | 46 | ## Sample “Deploy a Sovereign Rollup” workshop presentation 47 | 48 | - [Sample presentation - deploy a sovereign rollup](https://docs.google.com/presentation/d/163yP8lQ28k-xfL3jcdX2cfO-3zg8e63AOuHeHxde3vk/edit#slide=id.g20713cce7c2_1_596) 49 | - Summary: This is an overview presentation on deploying a sovereign rollup 50 | with Rollkit on Celestia. 51 | You can find existing video presentations for this here: 52 | - The sample presentation covers: 53 | 1. What is a sovereign rollup? 54 | 2. The role of sovereign rollups in the Celestia ecosystem 55 | 3. Introduction to Rollkit 56 | 4. Setting up a sovereign rollup: hardware and software requirements 57 | 5. Q&A session 58 | 59 | ## Sample “Modular Meetup Introduction” workshop presentation 60 | 61 | - [Sample presentation - modular meetup introduction](https://docs.google.com/presentation/d/1HIOKwnCRylofo4sp5I93hsfY3DKWbmXxfvMdoiIk-3I/edit?usp=sharing) 62 | - The sample presentation covers: 63 | 1. Introduction to Celestia and modular blockchains 64 | 2. Introduction to the Modular Meetup Program 65 | 3. Scope of the Program 66 | 4. Benefits 67 | 5. Speakers 68 | 6. Supporting the Program 69 | 70 | ## Swag logistics 71 | 72 | - Merchandise support 73 | 1. For merchandise support for your meetup, please email 74 | [natnet@celestia.org](mailto:natnet@celestia.org) 75 | 76 | With this Modular Meetups Organizer Kit, you’ll have everything 77 | you need to plan and execute engaging, informative, and successful 78 | meetups for the Celestia community. Happy organizing! 79 | -------------------------------------------------------------------------------- /community/speaker-list.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: Invite a speaker from the ecosystem to your Modular Meetup. 3 | --- 4 | 5 | # Speaker list 6 | 7 | As a Modular Meetup organizer, we understand the importance 8 | of delivering engaging and informative content to your attendees. 9 | That's why we've created an exclusive Speaker List specifically 10 | tailored for organizers participating in the Modular Meetup Program. 11 | This resource gives you access to a curated selection of top-tier 12 | speakers who are passionate about Celestia and the modular ecosystem. 13 | Due to privacy, the list is not shared publicly but is accessible 14 | to participants of the Modular Meetup program when they create a meetup. 15 | 16 | The Speaker List features experts from Celestia Labs, as well as prominent 17 | figures from the broader Celestia and modular communities. Each individual 18 | is well-versed in various aspects of the modular ecosystem, ensuring that 19 | your meetup attendees gain valuable insights and deepen their understanding 20 | of modular blockchains. 21 | 22 | By joining the Modular Meetup Program, you can enjoy the benefits of our Speaker 23 | List and bring a touch of expertise to your events. The speakers can participate 24 | either in person or virtually, depending on location and timing. 25 | 26 | You can expect benefits from the Speaker List, including high-quality presentations, 27 | interactive Q&A sessions, and knowledge-sharing opportunities facilitated by the 28 | best and brightest in the Celestia ecosystem. With our Speaker List, you'll be 29 | able to create memorable and impactful Modular Meetups that foster genuine 30 | connections and promote growth within the community. 31 | -------------------------------------------------------------------------------- /go.mod: -------------------------------------------------------------------------------- 1 | module celestia-docs-test 2 | 3 | go 1.23.6 4 | 5 | toolchain go1.23.8 6 | 7 | require ( 8 | github.com/celestiaorg/celestia-node v0.22.1 9 | github.com/celestiaorg/go-square/v2 v2.2.0 10 | ) 11 | 12 | replace ( 13 | github.com/cosmos/cosmos-sdk => github.com/celestiaorg/cosmos-sdk v1.28.2-sdk-v0.46.16 14 | github.com/filecoin-project/dagstore => github.com/celestiaorg/dagstore v0.0.0-20230824094345-537c012aa403 15 | github.com/gogo/protobuf => github.com/regen-network/protobuf v1.3.3-alpha.regen.1 16 | github.com/ipfs/boxo => github.com/celestiaorg/boxo v0.29.0-fork 17 | github.com/syndtr/goleveldb => github.com/syndtr/goleveldb v1.0.1-0.20210819022825-2ae1ddf74ef7 18 | github.com/tendermint/tendermint => github.com/celestiaorg/celestia-core v1.51.0-tm-v0.34.35 19 | ) -------------------------------------------------------------------------------- /how-to-guides/arbitrum-full-node.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: A guide on how to run a full node or validate a full node on your Orbit rollup. 3 | next: 4 | text: "Introduction to OP Stack integration" 5 | link: "/how-to-guides/intro-to-op-stack" 6 | --- 7 | 8 | # Running a full node and/or validator 9 | 10 | ## Prerequisites 11 | 12 | - Familiarity with Ethereum, Ethereum's testnets, Arbitrum, and Celestia 13 | - [A gentle introduction: Orbit chains](https://docs.arbitrum.io/launch-orbit-chain/orbit-gentle-introduction) 14 | - [Arbitrum Orbit integration overview](/how-to-guides/arbitrum-integration.md) 15 | 16 | ## Running a full node 17 | 18 | Running a fullnode or validator for an Orbit chain with Celestia DA is as simple as 19 | [following the steps outlined in the Arbitrum docs](https://docs.arbitrum.io/run-arbitrum-node/run-full-node), 20 | but using a docker image from the [latest stable release](https://github.com/celestiaorg/nitro/releases) of the Celestia integration and passing the following flags: 21 | 22 | - `node.celestia-cfg.enable=true` 23 | - `node.celestia-cfg.url=$URL_TO_DA_SERVER` 24 | 25 | or adding the following to your config: 26 | 27 | ``` 28 | "node": { 29 | ... 30 | "celestia-cfg": { 31 | "enable": true, 32 | "url": "DA_SERVER_URL" 33 | }, 34 | } 35 | ``` 36 | 37 | ## Running a Celestia DA server 38 | 39 | For instructions on how to run a DA server, please refer to the [repo docs](https://github.com/celestiaorg/nitro-das-celestia). 40 | 41 | Note that you can either run a light node, a bridge node, or a paid provider like [Quicknode](https://www.quicknode.com/docs/celestia) to connect your DA Server with the targeted Celestia network. 42 | 43 | ## Running a full node with validation 44 | 45 | The information above applies to 46 | [the steps outlined to run a validating full node (validator)](https://docs.arbitrum.io/node-running/how-tos/running-a-validator), with the addition of [configuring the DA Server to run as a validator](https://github.com/celestiaorg/nitro-das-celestia?tab=readme-ov-file#running-a-validator). 47 | 48 | Finally, note that this will require connection to a DA node, 49 | and we recommend running a Bridge node if you will be instantiating 50 | multiple rollups. 51 | -------------------------------------------------------------------------------- /how-to-guides/arbitrum-integration.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: An overview of the integration of Arbitrum Orbit with Celestia, detailing the key features and benefits, including the fallback mechanism to Anytrust and Ethereum. 3 | --- 4 | 5 | # Arbitrum Orbit with Celestia DA 6 | 7 | ![Celestia_Arbitrum](/img/Celestia-Arbitrum.png) 8 | 9 | ## Overview 10 | 11 | The 12 | [integration of Celestia with Arbitrum Orbit](https://blog.celestia.org/celestia-is-first-modular-data-availability-network-to-integrate-with-arbitrum-orbit/) 13 | and the Orbit stack marks the first external contribution to the Arbitrum 14 | Orbit protocol layer, offering developers an additional option for selecting 15 | a data availability layer alongside Arbitrum AnyTrust. The integration allows 16 | developers to deploy an Orbit Chain that uses Celestia for data availability. 17 | 18 | Learn more about Orbit in [Arbitrum's introduction](https://docs.arbitrum.io/launch-orbit-chain/orbit-gentle-introduction). 19 | 20 | ## Key components 21 | 22 | The integration of Celestia with Arbitrum Orbit is possible thanks to 3 key components: 23 | 24 | - [DA provider implementation](#da-provider-implementation) 25 | - [Preimage Oracle Implementation](#preimage-oracle-implementation) 26 | - [Blobstream integration](#blobstream-integration) 27 | 28 | Additionally, the [fallback mechanism](#fallback-mechanism-in-nitro) is a feature of the integration, which is native in Nitro. 29 | 30 | ### DA provider implementation 31 | 32 | The Arbitrum Nitro code has a set of `daprovider` interfaces to perform reads and writes for a given DA layer that are used across the codebase for EIP4844 Blobs, Anytrust, and Celestia DA. 33 | 34 | This integration implements the [`reader`](https://github.com/celestiaorg/nitro/blob/v3.5.2/das/celestia/types/reader.go) and [`writer`](https://github.com/celestiaorg/nitro/blob/v3.5.2/das/celestia/types/writer.go) interfaces. 35 | 36 | Additionally, the logic for reading, writing, and generating Celestia related proofs is moved to a sidecar [`celestia-server`](https://github.com/celestiaorg/nitro-das-celestia), which allows the Nitro node to request submissions and retrivals from a celestia node using an [`RPC client`](https://github.com/celestiaorg/nitro/blob/v3.5.2/das/celestia/celestiaDasRpcClient.go). 37 | 38 | To run the Celestia server see the [nitro-das-celestia](https://github.com/celestiaorg/nitro-das-celestia) repository for more instructions. 39 | 40 | ### Preimage Oracle Implementation 41 | 42 | In order to support fraud proofs, this integration has the necessary code for a Nitro validator to populate its preimage mapping with Celestia hashes that then get "unpeeled" in order to reveal the full data for a Blob. You can 43 | [read more about the "Hash Oracle Trick"](https://docs.arbitrum.io/inside-arbitrum-nitro/#readpreimage-and-the-hash-oracle-trick). 44 | 45 | The data structures and hashing functions for this can be found in the [`nitro/das/celestia/tree` directory](https://github.com/celestiaorg/nitro/tree/v3.5.2/das/celestia/tree) 46 | 47 | You can [see where the preimage oracle gets used in the fraud proof replay binary](https://github.com/celestiaorg/nitro/blob/v3.5.2/cmd/replay/main.go#L163-L274). 48 | 49 | ### Blobstream integration 50 | 51 | The integration ensures that in the case of a challenge in which the `ReadInboxMessage` instruction is disputed, that the corresponding batch can be confirmed to be in Celestia through the use of Blobstream (default is SP1 Blobstream by Succinct), which gives us strong security guarantees that the data was made available on Celestia. 52 | 53 | ### Fallback mechanism in Nitro 54 | 55 | Arbitrum Nitro natively supports the ability to "fallback" to Ethereum DA in case that writing a batch to Anytrust is unsuccessful, the Celestia DA integration goes a step beyond, enabling [fallbacks from any dapwriter to another](https://github.com/celestiaorg/nitro/blob/v3.5.2/arbnode/batch_poster.go#L1419-L1451) by introducing a [da-preference](https://github.com/celestiaorg/nitro/blob/v3.5.2/arbnode/node.go#L106) parameter to the node which allows developers to specify in which order they would like to prioritize fallbacks, for example, `["celestia", "anytrust"]` indicates the batch poster to first write to celestia, on failure fallback to anytrust, and on failure fallback to ethereum da or `"celestia" -> "anytrust" -> "blobs / calldata"` 56 | 57 | ## Next steps 58 | 59 | Follow the [quickstart](/how-to-guides/nitro-local.md) guide on the next page to run a local nitro chain with Nitro testnode. 60 | -------------------------------------------------------------------------------- /how-to-guides/audits.md: -------------------------------------------------------------------------------- 1 | # Audits 2 | 3 | This page provides a comprehensive list of audits conducted on various Celestia software, including OP Stack, Nitro, celestia-app, Blobstream, and more. Each audit is linked to its respective report. 4 | 5 | | Software | Auditor | Link | 6 | | -------------------------- | ---------------- | -------------------------------------------------------------------------------------------------------------------------- | 7 | | OP Stack | OtterSec | [Link](https://docs.celestia.org/audits/Celestia_OP_Stack_Audit.pdf) | 8 | | Nitro | OtterSec | [Link](https://github.com/celestiaorg/nitro/blob/celestia-v2.3.3/audits/celestia/arbitrum_nitro_celestia_audit_report.pdf) | 9 | | v2 celestia-app Lemongrass | Informal Systems | [Link](https://github.com/celestiaorg/celestia-app/blob/main/docs/audit/informal-systems-v2.pdf) | 10 | | v3 celestia-app | Informal Systems | [Link](https://github.com/celestiaorg/celestia-app/blob/main/docs/audit/informal-systems-authored-blobs.pdf) | 11 | | Blobstream SP1 | OtterSec | [Link](https://docs.celestia.org/audits/SP1_Blobstream_Ottersec_Audit.pdf) | 12 | | Blobstream SP1 | Multiple | [Link](https://github.com/succinctlabs/sp1/tree/dev/audits) | 13 | | Blobstream X | Informal Systems | [Link](https://docs.celestia.org/audits/Blobstream_X-Informal_Systems_Audit.pdf) | 14 | | Blobstream X | OtterSec | [Link](https://docs.celestia.org/audits/Blobstream_X-OtterSec_Audit.pdf) | 15 | | Blobstream X | Veridise | [Link](https://docs.celestia.org/audits/Blobstream_X-Veridise_Audit.pdf) | 16 | | Blobstream X | Zellic | [Link](https://docs.celestia.org/audits/Blobstream_X-Zellic_Audit.pdf) | 17 | | Shwap | OtterSec | [Link](https://docs.celestia.org/audits/celestia_shwap_audit_final.pdf) | 18 | | v4 celestia-app | TBD | TBD | 19 | | v5 celestia-app | TBD | TBD | 20 | | ZK Sync | TBD | TBD | 21 | -------------------------------------------------------------------------------- /how-to-guides/blobstream-x-requesting-data-commitment-ranges.md: -------------------------------------------------------------------------------- 1 | --- 2 | prev: 3 | text: "Overview of Blobstream X" 4 | link: "/how-to-guides/blobstreamx" 5 | --- 6 | 7 | # Requesting data commitment ranges 8 | 9 | :::warning DEPRECATED 10 | This documentation is for BlobstreamX, which is the previous implementation of Blobstream. 11 | The [BlobstreamX repository](https://github.com/succinctlabs/blobstreamx) is now archived. 12 | 13 | For current deployments, see [SP1 Blobstream](/how-to-guides/sp1-blobstream-deploy.md) documentation. 14 | ::: 15 | 16 | By default, the Blobstream X deployments on Ethereum will be 17 | updated every 4 hours, and on Arbitrum One 18 | and Base, updating every 1 hour. If you wish for the Blobstream X contract 19 | to be updated at a different cadence, then you have several different 20 | options for how to update the smart contract. 21 | 22 | To request proofs to be submitted to the Blobstream X contract at a 23 | different cadence, you can do one of the following: 24 | 25 | > **_NOTE:_** The requested proof ranges cannot include 26 | > blocks that were already used in a previous batch. 27 | > The ranges should start from the last proven block, aka, 28 | > [`latest_block`](https://github.com/succinctlabs/blobstreamx/blob/aac0842f17056e5343f66de7df44020c1637e8b7/contracts/src/BlobstreamX.sol#L16-L17) 29 | > and they should end in a block already committed by Celestia. 30 | > In other words, it's the end-inclusive range defined 31 | > by `[latest_block, target_block]` with `target_block` <= Celestia tip. 32 | 33 | ## Local proving 34 | 35 | To run the Blobstream X operator with local proving, follow this [guide](https://hackmd.io/@succinctlabs/HJE7XRrup). 36 | 37 | Local proving allows self-generating the proofs and submitting them to an existing BlobstreamX contract. 38 | Alternatively, if a team needs a very specific cadence that starts at very specific heights, they can deploy their own 39 | BlobstreamX contract and submit proofs to it. Deployment instructions can be found in the [BlobstreamX deploy](/how-to-guides/blobstream-x-deploy.md) 40 | documentation. 41 | 42 | ::: tip 43 | Requires a large cloud machine to run in a reasonable 44 | amount of time. EC2 r6a.16xlarge, i.e., 64CPU 512GB RAM, takes ~30 minutes to generate a 45 | header range proof. 46 | ::: 47 | 48 | ## Request proofs from the Succinct platform 49 | 50 | > **_NOTE:_** Requesting a proof from the succinct platform requires 51 | > having a Succinct API key. 52 | 53 | Run the Blobstream X operator with hosted proving on the Succinct 54 | platform, by running an operator script that pings the platform with 55 | proof requests at a specified cadence. 56 | 57 | Follow [these instructions](https://github.com/succinctlabs/blobstreamx?tab=readme-ov-file#operator-with-hosted-proving) 58 | to run the operator script. 59 | 60 | Here are example values for the `.env` file: 61 | 62 | 1. `TENDERMINT_RPC_URL` from 63 | [the public Celestia list](https://docs.celestia.org/how-to-guides/mainnet#integrations). 64 | 2. `SUCCINCT_RPC_URL` = `https://alpha.succinct.xyz/api` 65 | 3. Request for `SUCCINCT_API_KEY` from the Succinct team. 66 | 4. `CHAIN_ID` is the chain ID of the deployed Blobstream X contract. 67 | 5. `CONTRACT_ADDRESS`: Blobstream X proxy contract address. 68 | 6. `NEXT_HEADER_FUNCTION_ID` & `HEADER_RANGE_FUNCTION_ID`: Get the 69 | `functionId`'s from the Blobstream X contract by using the 70 | `nextHeaderFunctionId` and `headerRangeFunctionId` respectively, 71 | which are public storage variables. 72 | 73 | ## Request proofs onchain 74 | 75 | Directly request a proof via the Blobstream X contract interface. 76 | Unlike the Blobstream X operator which handles requests off-chain, 77 | requesting on-chain requires gas, but the proof will be generated 78 | and relayed by the Succinct platform. 79 | 80 | 1. Call `requestHeaderRange(uint64 _targetBlock)` with the end 81 | of the range you want a commitment for. 82 | 83 | 2. A `DataCommitmentStored(uint256, uint64, uint64, bytes32)` 84 | will be emitted for the requested range when it is stored in the 85 | contract. Listen to this event to know that the proof has been 86 | generated successfully. 87 | -------------------------------------------------------------------------------- /how-to-guides/blobstreamx.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: What is BlobstreamX 3 | prev: 4 | text: "New SP1 Blobstream deployments" 5 | link: "/how-to-guides/sp1-blobstream-deploy" 6 | --- 7 | 8 | # Blobstream X: the previous zk implementation of Blobstream 9 | 10 | ![blobstream x draft diagram](/img/blobstream/Celestia_Blobstream_X1b.png) 11 | 12 | ## What is Blobstream X? 13 | 14 | Blobstream X is the previous implementation of Blobstream. It uses 15 | [plonky2x](https://github.com/succinctlabs/succinctx/tree/main/plonky2x) to create 16 | circuits that verify the Celestia consensus and generate the corresponding proofs. 17 | 18 | :::tip NOTE 19 | The [Blobstream X repository](https://github.com/succinctlabs/blobstreamx) is now archived. 20 | For current deployments and active development, see [SP1 Blobstream](https://github.com/succinctlabs/sp1-blobstream). 21 | ::: 22 | 23 | Blobstream X is built and deployed with 24 | [Succinct's protocol](https://docs.succinct.xyz). 25 | 26 | :::tip NOTE 27 | Current Blobstream deployments use SP1 Blobstream, not BlobstreamX circuits. 28 | This documentation is maintained for historical reference. 29 | ::: 30 | 31 | You can [find the repository for Blobstream X](https://github.com/succinctlabs/blobstreamx) 32 | along with code for: 33 | 34 | - [The Blobstream X smart contract - `BlobstreamX.sol`](https://github.com/succinctlabs/blobstreamx/blob/main/contracts/src/BlobstreamX.sol) 35 | - The Blobstream X circuits 36 | - [The Blobstream X contract Golang bindings](https://github.com/succinctlabs/blobstreamx/blob/main/bindings/BlobstreamX.go) 37 | 38 | :::tip NOTE 39 | Custom ranges can be requested using the `BlobstreamX` contract 40 | to create proofs for specific Celestia block batches. These ranges 41 | can be constructed as `[latestBlock, customTargetBlock)`, with 42 | `latestBlock` as the latest block height that was committed to by the 43 | `BlobstreamX` contract, and `latestBlock > customTargetBlock`, 44 | and `customTargetBlock - latestBlock <= DATA_COMMITMENT_MAX`. 45 | 46 | Block ranges that are before the contract's `latestBlock` can't be 47 | proven a second time in different batches. 48 | 49 | More information can be found in the [`requestHeaderRange(...)`](https://github.com/succinctlabs/blobstreamx/blob/364d3dc8c8dc9fd44b6f9f049cfb18479e56cec4/contracts/src/BlobstreamX.sol#L78-L101) 50 | method. 51 | ::: 52 | 53 | ## How Blobstream X works 54 | 55 | As shown in the diagram below, the entrypoint for updates to the Blobstream 56 | X contract is through the `SuccinctGateway` smart contract, which is a 57 | simple entrypoint contract that verifies proofs (against a deployed 58 | onchain verifier for the Blobstream X circuit) and then calls the 59 | `BlobstreamX.sol` contract to update it. 60 | 61 | ![blobstream x overview diagram draft](/img/blobstream/Celestia_Blobstream_X2b.png) 62 | 63 | 64 | 65 | :::tip NOTE 66 | If the Blobstream X contract is not deployed on a desired chain, 67 | it needs to be deployed before it can be used by your rollup. 68 | ::: 69 | 70 | ## Deploy Blobstream X 71 | 72 | It is possible to deploy and maintain a Blobstream x instance and have the same security guarantees. 73 | 74 | First, you will need to create a multisig that governs the Blobstream X contract and also the function identifiers. 75 | 76 | Then, check the [deployment](https://github.com/succinctlabs/blobstreamx/blob/main/README.md#blobstreamx-contract-overview) documentation for how to deploy the contract. 77 | 78 | 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](/how-to-guides/blobstream-x-requesting-data-commitment-ranges.md#local-proving) for more information. 79 | 80 | ## Community implementations 81 | 82 | Learn more about the community [implementation of Blobstream proofs by CryptoKass](https://github.com/CryptoKass/blobstreamx-example). 83 | -------------------------------------------------------------------------------- /how-to-guides/celestia-app-metrics.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: A guide on how to monitor the health and performance of your system. 3 | prev: 4 | text: "Troubleshooting" 5 | link: "/how-to-guides/celestia-node-troubleshooting" 6 | --- 7 | 8 | # Metrics 9 | 10 | Metrics are a powerful tool for monitoring the health 11 | and performance of a system. Celestia provides support 12 | for metrics to make sure, as an operator, your system 13 | continues to remain up and running. Metrics can also 14 | provide critical insight into how Celestia is used and 15 | how it can be improved. 16 | 17 | ## Setup 18 | 19 | Celestia uses [Prometheus](https://prometheus.io/) to 20 | publish metrics. It can be enabled through the `config.toml` file. 21 | 22 | ```bash 23 | ####################################################### 24 | ### Instrumentation Configuration Options ### 25 | ####################################################### 26 | [instrumentation] 27 | 28 | # When true, Prometheus metrics are served under /metrics on 29 | # PrometheusListenAddr. 30 | # Check out the documentation for the list of available metrics. 31 | prometheus = true 32 | 33 | # Address to listen for Prometheus collector(s) connections 34 | prometheus_listen_addr = ":26660" 35 | 36 | # Maximum number of simultaneous connections. 37 | # If you want to accept a larger number than the default, make sure 38 | # you increase your OS limits. 39 | # 0 - unlimited. 40 | max_open_connections = 3 41 | 42 | # Instrumentation namespace 43 | namespace = "celestia" 44 | ``` 45 | 46 | If you restart your node, you can check to see it's working 47 | by running: 48 | 49 | ```bash 50 | curl localhost:26660/metrics 51 | ``` 52 | 53 | ## Visualization 54 | 55 | Now your nodes are publishing metrics, we need something to 56 | scrape it and a visualizer to create a dashboard. Commonly, 57 | Prometheus is paired with Grafana. 58 | 59 | First, you will need to install Prometheus either from their 60 | [downloads page](https://prometheus.io/download/) or through 61 | a package manager like `brew`. 62 | 63 | Next, create a config file `$HOME/.celestia-app/config/prometheus.yml` 64 | and fill out some basic settings as follows: 65 | 66 | 67 | 68 | ```yml 69 | global: 70 | scrape_interval: 15s # By default, scrape targets every 15 seconds. 71 | 72 | # Attach these labels to any time series or alerts when communicating 73 | # with external systems (federation, remote storage, Alertmanager). 74 | external_labels: 75 | monitor: "codelab-monitor" 76 | 77 | # A scrape configuration containing exactly one endpoint to scrape: 78 | # Here it's Prometheus itself. 79 | scrape_configs: 80 | # The job name is added as a label `job=` to any timeseries 81 | # scraped from this config. 82 | - job_name: "prometheus" 83 | 84 | # Override the global default and scrape targets from this job every 85 | # 5 seconds. 86 | scrape_interval: 5s 87 | 88 | static_configs: 89 | # Point to the same endpoint that Celestia is publishing on 90 | - targets: ["localhost:26660"] 91 | ``` 92 | 93 | 94 | 95 | Note, that Prometheus by default runs its server on `:9090`. 96 | If you are running this on the same machine as your consensus 97 | node, it will collide with gRPC which runs on the same port. 98 | To avoid this, either switch off gRPC (if it's not needed), 99 | change the gRPC port in `app.toml`, or run Prometheus on a 100 | different port e.g. `--web.listen-address="0.0.0.0:8000"` 101 | 102 | To run the prometheus server: 103 | 104 | ```bash 105 | prometheus --config.file="$HOME/.celestia-app/config/prometheus.yml" 106 | ``` 107 | 108 | A prometheus server can scrape metrics from multiple nodes at once; 109 | a good way of bringing together information from many machines to one place. 110 | 111 | To visualize the information, you can use [Grafana](https://grafana.com/): 112 | either with their cloud option or run the [open source code](https://grafana.com/grafana/download?pg=graf&platform=linux&plcmt=deploy-box-1) 113 | yourself. 114 | 115 | Once setup, run: 116 | 117 | ```bash 118 | grafana server 119 | ``` 120 | 121 | which will begin a server on `localhost:3000`. 122 | If you open the url on your browser you will 123 | see the Grafana login page. Use `admin` for both 124 | the user and password to log in. 125 | 126 | You will need to link the prometheus server as a 127 | data source. To do that go to "Configuration" in 128 | the sidebar and then "Data Sources". Add a new data 129 | source specifying the URL of the Prometheus instance 130 | (default at `localhost:9090`). Click "Save & test" to confirm. 131 | 132 | Lastly, you will need to setup a dashboard. You can 133 | choose to do this yourself, handpicking the metrics 134 | that are important or you can simply export an existing 135 | design. Fortunately the cosmos ecosystem has conjured a 136 | "Cosmos Dashboard". On the sidebar, click "Dashboards" 137 | and then "import". Enter the following dashboard ID: 11036 138 | and then link it to the "Prometheus" data source you just set up. 139 | Finally click the "Import" button and the "Cosmos Dashboard" should appear. 140 | 141 | ## Node exporter 142 | 143 | Celestia's metrics include a plethora of application specific 144 | trackers but it's also important to keep an eye on system level 145 | metrics such as memory usage and disk space. This can be best 146 | achieved by running [Node Exporter](https://prometheus.io/docs/guides/node-exporter/). 147 | Follow the guide in the link to get set up, adding the port 148 | number to the `prometheus.yml` file. 149 | 150 | ## Alerts 151 | 152 | The final cherry on the cake is to integrate your monitoring 153 | system with a mechanism for producing alerts to warn you if 154 | your node has crashed or is no longer able to stay at the head 155 | of the chain. 156 | 157 | Since we're already using Grafana, we can install the 158 | [Grafana OnCall](http://localhost:3000/plugins/grafana-oncall-app) 159 | plugin. OnCall allows you to setup integrations. It could be a 160 | webhook or a direct integration into Telegram or Slack. 161 | You can find more information on Grafana's [Docs Page](https://grafana.com/docs/oncall/latest/integrations/). 162 | -------------------------------------------------------------------------------- /how-to-guides/celestia-app-multisig.md: -------------------------------------------------------------------------------- 1 | # Multisig 2 | 3 | Celestia inherits support for multisig accounts from the Cosmos SDK. Multisig 4 | accounts behave similarly to regular accounts with the added requirement that 5 | a threshold of signatures is needed to authorize a transaction. 6 | 7 | Multisig accounts can be created from the [command line](#command-line) or using 8 | a graphical interface such as [Keplr](https://multisig.keplr.app/). 9 | 10 | ## Command line 11 | 12 | ```bash 13 | #!/bin/sh 14 | 15 | # Prerequisite: prior to running this script, start a single node devnet with ./scripts/single-node.sh 16 | CHAIN_ID="private" 17 | KEY_NAME="validator" 18 | KEYRING_BACKEND="test" 19 | BROADCAST_MODE="block" 20 | 21 | # Create 3 test keys 22 | celestia-appd keys add test1 23 | celestia-appd keys add test2 24 | celestia-appd keys add test3 25 | # Create the multisig account 26 | celestia-appd keys add multisig \ 27 | --multisig test1,test2,test3 \ 28 | --multisig-threshold 2 29 | 30 | # Send some funds from the validator account to the multisig account 31 | celestia-appd tx bank send $VALIDATOR $MULTISIG 100000utia \ 32 | --from $VALIDATOR \ 33 | --fees 1000utia \ 34 | --chain-id $CHAIN_ID \ 35 | --keyring-backend $KEYRING_BACKEND \ 36 | --broadcast-mode $BROADCAST_MODE \ 37 | --yes 38 | 39 | # Send some funds from the multisig account to the validator account. 40 | # Note this transaction will need to be signed by at least 2 of the 3 test accounts. 41 | celestia-appd tx bank send $MULTISIG $VALIDATOR 1utia \ 42 | --from $MULTISIG \ 43 | --fees 1000utia \ 44 | --chain-id $CHAIN_ID \ 45 | --keyring-backend $KEYRING_BACKEND \ 46 | --generate-only > unsignedTx.json 47 | 48 | # Sign from test1 and test2 49 | celestia-appd tx sign unsignedTx.json \ 50 | --multisig $MULTISIG \ 51 | --from test1 \ 52 | --output-document test1sig.json \ 53 | --chain-id $CHAIN_ID 54 | celestia-appd tx sign unsignedTx.json \ 55 | --multisig $MULTISIG \ 56 | --from test2 \ 57 | --output-document test2sig.json \ 58 | --chain-id $CHAIN_ID 59 | 60 | # Generate the final signed transaction 61 | celestia-appd tx multisign unsignedTx.json multisig \ 62 | test1sig.json test2sig.json \ 63 | --output-document signedTx.json \ 64 | --chain-id $CHAIN_ID 65 | ``` 66 | 67 | ## Resources 68 | 69 | - 70 | - 71 | - 72 | -------------------------------------------------------------------------------- /how-to-guides/celestia-app-slashing.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: This section covers the jailing and slashing mechanics for validators in Celestia. 3 | --- 4 | 5 | # Jailing and slashing on Celestia 6 | 7 | Slashing is a mechanism employed in proof of stake blockchains 8 | that is used to deter and punish malicious behavior. 9 | It functions by removing a percentage of a validator's stake 10 | each time they act harmfully towards the network. 11 | 12 | Celestia is built with the Cosmos SDK and uses the `x/slashing` module. 13 | 14 | If a validator gets slashed, delegators bonded to that validator will also 15 | have the same percentage of their delegated funds slashed. 16 | 17 | The following are the conditions for a validator to get jailed or slashed: 18 | 19 | 1. **Downtime**: If a validator is offline for more than 25% of a rolling window 20 | of the last 5,000 blocks, they will be jailed for 1 minute. 21 | During this period, the validator is removed from the validator set 22 | temporarily, and will be unable to propose new blocks or earn rewards. 23 | After the jail period, the validator can send an unjail request to 24 | rejoin the validator set. 25 | 26 | 2. **Double signing**: This is a more severe offense and results in getting slashed. 27 | If a validator engages in double signing, the validator 28 | will lose 2% of their stake and the remainder of their stake 29 | will be returned to them. The validator will be permanently removed 30 | from the validator set and will not have the ability to unjail. 31 | Delegators bonded to that validator will automatically enter the unbonding 32 | period for 21 days, and can delegate to another validator after 33 | they have been unbonded. 34 | 35 | For more details on the jailing and slashing parameters, refer to the 36 | [celestia-app specifications](https://celestiaorg.github.io/celestia-app/specs/params.html#module-parameters) 37 | page. 38 | -------------------------------------------------------------------------------- /how-to-guides/celestia-app-upgrade-monitor.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: upgrade-monitor is a tool to monitor upgrades on a Celestia network. 3 | --- 4 | 5 | # Upgrade Monitor 6 | 7 | Upgrade monitor is a binary that monitors that status of upgrades on a Celestia 8 | network. See the [README](https://github.com/celestiaorg/upgrade-monitor) for 9 | instructions on how to install and use the binary. 10 | -------------------------------------------------------------------------------- /how-to-guides/celestia-app-wallet.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: Learn how to generate a Celestia wallet using celestia-app. 3 | --- 4 | 5 | # Create a wallet with celestia-app 6 | 7 | For this guide, we will go over how you can generate a Celestia 8 | wallet using celestia-app. 9 | 10 | ## Prerequisites 11 | 12 | - Gone through [quick start and Installed celestia-app](/how-to-guides/quick-start.md) 13 | 14 | Note, you do not need to install celestia-node for this tutorial. 15 | 16 | ## Create a wallet 17 | 18 | First, create an application CLI configuration file: 19 | 20 | ```sh 21 | celestia-appd config keyring-backend test 22 | ``` 23 | 24 | You can pick whatever wallet name you want. 25 | For our example we used "validator" as the wallet name: 26 | 27 | ```sh 28 | celestia-appd keys add validator --interactive 29 | ``` 30 | 31 | Save the mnemonic output as this is the only way to 32 | recover your validator wallet in case you lose it! 33 | 34 | To check all your wallets you can run: 35 | 36 | ```sh 37 | celestia-appd keys list 38 | ``` 39 | 40 | ## Fund a wallet 41 | 42 | For the public celestia address, you can fund the 43 | previously created wallet via [Discord](https://discord.gg/celestiacommunity) 44 | by sending this message to either the #mocha-faucet or #arabica-faucet channel: 45 | 46 | ```text 47 | $request celestia1xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 48 | ``` 49 | 50 | Wait to see if you get a confirmation that the 51 | tokens have been successfully sent. To check if 52 | tokens have arrived successfully to the destination 53 | wallet run the command below replacing the public 54 | address with your own: 55 | 56 | ```sh 57 | celestia-appd start 58 | celestia-appd query bank balances celestia1xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 59 | ``` 60 | 61 | :::tip 62 | Refer to 63 | [the ports section of the celestia-node troubleshooting page](/how-to-guides/celestia-node-troubleshooting.md#ports) 64 | for information on which ports are required to be open on your machine. 65 | ::: 66 | -------------------------------------------------------------------------------- /how-to-guides/celestia-node-custom-networks.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: Learn about custom networks and values on celestia-node. 3 | --- 4 | 5 | # Custom networks and values 6 | 7 | This section will cover importing bootstrapper IDs, chain ID, 8 | and network ID. This will allow you to import custom values 9 | for a chain that is not in the default configuration. 10 | 11 | If you have a custom network you can export `CELESTIA_CUSTOM`, which will 12 | look something like: 13 | 14 | ```bash 15 | export BRIDGE="/ip4//tcp/2121/p2p/" 16 | export GENESIS_HASH= 17 | export NETWORK= 18 | export CELESTIA_CUSTOM="${NETWORK}:${GENESIS_HASH}:${BRIDGE}" 19 | ``` 20 | 21 | Query your node ID [using the RPC CLI](/tutorials/node-tutorial.md#get-your-node-id). 22 | These values with examples would look like: 23 | 24 | ```bash 25 | export BRIDGE="/ip4/151.115.14.33/tcp/2121/p2p/12D3KooWKEeRtzVMPUdxYsZo2edqps6mS67n6LT5mPdULSkPSxBQ" 26 | export GENESIS_HASH=580B3DFF8A7C716968161D91116A1E171F486298D582874E93714E489C9E6E88 27 | export NETWORK=custom 28 | export CELESTIA_CUSTOM="${NETWORK}:${GENESIS_HASH}:${BRIDGE}" 29 | ``` 30 | 31 | Then, start your node with: 32 | 33 | ```bash 34 | celestia start [flags...] 35 | ``` 36 | -------------------------------------------------------------------------------- /how-to-guides/celestia-node-metrics.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: A guide on how to run metrics for your celestia-node DA instance. 3 | --- 4 | 5 | # celestia-node metrics 6 | 7 | This tutorial is for running metrics for your celestia-node data 8 | availability instance. This tutorial will focus on running metrics for a light node. 9 | 10 | This tutorial assumes you have already setup your light node 11 | by following the tutorial in the 12 | [celestia-node API tutorial](/tutorials/node-tutorial.md). 13 | 14 | ## Running metrics flags 15 | 16 | You can enable the `celestia-node` metric flags with the following 17 | command: 18 | 19 | ```sh 20 | celestia start --metrics.tls= \ 21 | --metrics --metrics.endpoint \ 22 | --p2p.network \ 23 | --core.ip --core.port 24 | ``` 25 | 26 | Add metrics flags to your node start command and restart your node to apply it. 27 | The metrics endpoint will gather your node's data to track your uptime. 28 | 29 | Note that the `--metrics` flag enables metrics and expects 30 | an input into `--metrics.endpoint`. 31 | 32 | We will go over what the endpoint will need to be in the 33 | [metrics endpoint design considerations](#metrics-endpoint-design-considerations) 34 | section. 35 | 36 | ### Mainnet Beta 37 | 38 | Here is an example for Mainnet Beta: 39 | 40 | ```sh 41 | celestia start --metrics.tls=true \ 42 | --metrics --metrics.endpoint otel.celestia.observer \ 43 | --core.ip --core.port 44 | ``` 45 | 46 | ### Mocha testnet 47 | 48 | Here is an example for Mocha testnet: 49 | 50 | ```sh 51 | celestia start --metrics.tls=true \ 52 | --metrics --metrics.endpoint otel.mocha.celestia.observer \ 53 | --core.ip --core.port --p2p.network mocha 54 | ``` 55 | 56 | ### Arabica devnet 57 | 58 | Here is an example for Arabica devnet: 59 | 60 | ```sh 61 | celestia start --metrics.tls=true \ 62 | --metrics --metrics.endpoint otel.arabica.celestia.observer \ 63 | --core.ip --core.port --p2p.network arabica 64 | ``` 65 | 66 | ### TLS connections 67 | 68 | The `--metrics.tls` flag enables or disables a TLS connection to the 69 | OpenTelemetry Protocol metrics backend. You need to choose a boolean 70 | value (`true` or `false`) for this flag. 71 | 72 | It's also common to set this flag to `false` when spinning up a local 73 | collector 74 | to check the metrics locally. 75 | 76 | However, if the collector is hosted in the cloud as a separate entity 77 | (like in a DevOps environment), enabling TLS is a necessity for secure 78 | communication. 79 | 80 | Here are examples of how to use it: 81 | 82 | ```bash 83 | # To enable TLS connection 84 | celestia start --metrics.tls=true --metrics \ 85 | --metrics.endpoint \ 86 | --p2p.network --core.ip --core.port 87 | 88 | # To disable TLS connection 89 | celestia start --metrics.tls=false --metrics \ 90 | --metrics.endpoint \ 91 | --p2p.network --core.ip --core.port 92 | ``` 93 | 94 | ## Metrics endpoint design considerations 95 | 96 | At the moment, the architecture of celestia-node metrics 97 | works as specified in the following [ADR #010](https://github.com/celestiaorg/celestia-node/blob/main/docs/adr/adr-010-incentivized-testnet-monitoring.md). 98 | 99 | Essentially, the design considerations here will necessitate 100 | running an OpenTelemetry (OTEL) collector that connects to Celestia 101 | light node. 102 | 103 | For an overview of OTEL, check out [the guide](https://opentelemetry.io/docs/collector). 104 | 105 | The ADR and the OTEL docs will help you run your collector on the metrics endpoint. 106 | This will then allow you to process the data in the collector on a 107 | Prometheus server which can then be viewed on a Grafana dashboard. 108 | 109 | In the future, we do want to open-source some developer toolings around 110 | this infrastructure to allow for node operators to be able to monitor 111 | their data availability nodes. 112 | -------------------------------------------------------------------------------- /how-to-guides/celestia-node-store-structure.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: This section contains information on the celestia-node datastore and its contents. 3 | --- 4 | 5 | # celestia-node datastore 6 | 7 | The node's datastore refers to the storage structure 8 | used to manage the data that supports the node's operation. 9 | It consists of directories and files that contain the node's state, 10 | configuration, and other information relevant to the node. 11 | 12 | The following are the directories and files found in the datastore: 13 | 14 | - `/blocks`: This directory stores blocks. Each file contained in this directory 15 | represents a block on Celestia and contains its associated data. This directory is present in the datastore for bridge and full nodes but not light nodes, as light nodes do not store blocks. 16 | 17 | - `/data`: This directory contains block headers and various files belonging to the node's log-structured merge (LSM) storage system. The LSM files (such as `DISCARD`, `KEYREGISTRY`, and `MANIFEST`) manage the efficient storage and retrieval of data. 18 | 19 | - `/index`: This directory stores the index files that handle mapping specific keys such as block heights, to the corresponding data. Similar to `/blocks`, the light node's datastore does not include this directory, as they do not perform indexing. 20 | 21 | - `/inverted_index`: This directory stores the inverted index files used for mapping queries to the corresponding data location, along with associated LSM storage system files. The light node's datastore does not contain this directory. 22 | - `/keys`: This directory stores the cryptographic key pairs that are used to operate the node. 23 | 24 | - `/transients`: This directory contains temporary data such as cache files 25 | that are used while the node is operating, but are not a part of the permanent blockchain state. 26 | 27 | - `config.toml`: Located in the node's root directory, this is the primary configuration file that defines core settings such as network parameters, P2P configuration, and API endpoints. This file is generated during node initialization. 28 | -------------------------------------------------------------------------------- /how-to-guides/celestia-node-trusted-hash.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: How to sync a light node from a trusted hash. 3 | --- 4 | 5 | # Syncing a light node from a trusted hash 6 | 7 | This guide goes over how to sync a DA light node from a trusted hash. 8 | The example uses the Mocha testnet. You will need to adjust the commands accordingly for Mainnet Beta, Arabica, or a custom network. 9 | 10 | ::: warning 11 | Syncing to a trusted hash means that you will not sample the entire chain. This adds a trust 12 | assumption that you trust the history of the chain up to that point and that you trust the entity 13 | where you get the hash from. In this example, the trusted entity is a consensus endpoint or 14 | Celenium. 15 | ::: 16 | 17 | ## General Approach 18 | 19 | 1. Get trusted height & hash from a consensus endpoint or [Celenium](https://celenium.io). 20 | 2. Initialize the node store 21 | 22 | ```sh 23 | celestia light init --p2p.network 24 | ``` 25 | 26 | 3. Set the trusted height & hash in your config file 27 | 1. Open your `config.toml` at `.celestia-light/config.toml` (or `.celestia-light-/config.toml`) 28 | 2. Set `DASer.SampleFrom` to the trusted height (e.g. `SampleFrom = 123456`) 29 | 3. Set `Header.TrustedHash` to the trusted hash (e.g. `TrustedHash = ""`) 30 | 4. Run the node: 31 | 32 | ```sh 33 | celestia light start --p2p.network --core.ip --core.port 34 | ``` 35 | 36 | ## Automated Approach 37 | 38 | You can automate the process of setting the trusted height and hash using the following commands for Mocha testnet: 39 | 40 | ### 1. Initialize the node store (if not already done) 41 | 42 | ```sh 43 | celestia light init --p2p.network mocha 44 | ``` 45 | 46 | ### 2. Get and set the trusted height and hash automatically 47 | 48 | ```sh 49 | # Get both the height and hash values in a single call 50 | read -r TRUSTED_HEIGHT TRUSTED_HASH <<<"$(curl -s https://rpc-mocha.pops.one/header | jq -r '.result.header | "\(.height) \(.last_block_id.hash)"')" && export TRUSTED_HEIGHT TRUSTED_HASH 51 | 52 | # Use sed to find and replace the SampleFrom value in the config file (macOS version) 53 | sed -i '' "s/SampleFrom = .*/SampleFrom = $TRUSTED_HEIGHT/" ~/.celestia-light-mocha-4/config.toml 54 | 55 | # Add/update the TrustedHash value 56 | sed -i '' "s/TrustedHash = .*/TrustedHash = \"$TRUSTED_HASH\"/" ~/.celestia-light-mocha-4/config.toml 57 | 58 | # Display the updated values to confirm 59 | echo "SampleFrom updated to: $TRUSTED_HEIGHT" 60 | echo "TrustedHash updated to: $TRUSTED_HASH" 61 | ``` 62 | 63 | ### 3. Start the node 64 | 65 | ```sh 66 | celestia light start --p2p.network mocha --core.ip rpc-mocha.pops.one --core.port 9090 67 | ``` 68 | 69 | ::: tip 70 | For Linux users, remove the empty string (`''`) after `-i` in the `sed` commands: 71 | 72 | ```sh 73 | sed -i "s/SampleFrom = .*/SampleFrom = $TRUSTED_HEIGHT/" ~/.celestia-light-mocha-4/config.toml 74 | sed -i "s/TrustedHash = .*/TrustedHash = \"$TRUSTED_HASH\"/" ~/.celestia-light-mocha-4/config.toml 75 | ``` 76 | 77 | ::: 78 | 79 | ## For service operators 80 | 81 | If you're using multiple light nodes for similar services like tracking the same rollup, 82 | it is recommended to use the same hash and height for all services using 83 | the same starting height. 84 | -------------------------------------------------------------------------------- /how-to-guides/celestia-node.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: Learn to build and install celestia-node. 3 | --- 4 | 5 | # Install celestia-node 6 | 7 | 8 | 14 | 15 | ## Supported architectures 16 | 17 | Celestia-node officially supports the following architectures: 18 | 19 | - linux/amd64 20 | - linux/arm64 21 | - darwin/amd64 (macOS Intel) 22 | - darwin/arm64 (macOS Apple Silicon) 23 | 24 | Only these four architectures are officially tested and supported. 25 | 26 | ## Installing from source 27 | 28 | This section goes over building and installing celestia-node. This 29 | tutorial assumes you completed the steps in 30 | [setting up your development environment](/how-to-guides/environment.md). 31 | 32 | Install the celestia-node binary by running the following 33 | commands: 34 | 35 | 1. Remove any existing copy of celestia-node, clone the repository, 36 | and change into the directory: 37 | 38 | ```bash 39 | cd $HOME 40 | rm -rf celestia-node 41 | git clone https://github.com/celestiaorg/celestia-node.git 42 | cd celestia-node/ 43 | ``` 44 | 45 | 2. Check out to the desired version, based on the network you will use: 46 | 47 | ::: code-group 48 | 49 | ```bash-vue [Mainnet Beta] 50 | git checkout tags/{{mainnetVersions['node-latest-tag']}} 51 | ``` 52 | 53 | ```bash-vue [Mocha] 54 | git checkout tags/{{mochaVersions['node-latest-tag']}} 55 | ``` 56 | 57 | ```bash-vue [Arabica] 58 | git checkout tags/{{arabicaVersions['node-latest-tag']}} 59 | ``` 60 | 61 | ::: 62 | 63 | 3. Build the `celestia` binary: 64 | 65 | a. Standard build 66 | 67 | ```bash 68 | make build 69 | ``` 70 | 71 | b. Experimental build 72 | 73 | :::tip OPTIONAL 74 | If you're a node operator comfortable with experimental features and 75 | seeking optimal performance with minimal RAM usage, this option is 76 | recommended for you. 77 | 78 | ```bash 79 | make build-jemalloc 80 | ``` 81 | 82 | This build option enables CGO, and downloads and installs 83 | [jemalloc](https://jemalloc.net/). 84 | [Learn more about the build command](https://github.com/celestiaorg/celestia-node/releases/tag/v0.12.1#:~:text=%F0%9F%8F%97%EF%B8%8F-,New%20build%20option,-%3A%20Makefile%20now%20has). 85 | ::: 86 | 87 | 4. Install the binary: 88 | 89 | ```bash 90 | make install 91 | ``` 92 | 93 | 5. Build and install the `cel-key` utility: 94 | 95 | ```bash 96 | make cel-key 97 | make install-key 98 | ``` 99 | 100 | 6. Verify that the binary is working and check the version: 101 | 102 | ```bash 103 | celestia version 104 | ``` 105 | 106 | The output will show the semantic version of celestia-node, 107 | commit hash, build date, system version, and Golang version. 108 | 109 | ## Installing a pre-built binary 110 | 111 | Installing a pre-built binary is the fastest way to get started with your Celestia data availability node. Releases after celestia-node v0.13.3 have these binaries available. 112 | 113 | The installation script will download a binary file named `celestia`. Depending on your chosen installation option, the `celestia` binary will be available at one of these locations: 114 | 115 | - `$GOPATH/bin/celestia` (if Go is installed) 116 | - `/usr/local/bin/celestia` 117 | - `$HOME/celestia-node-temp/celestia` 118 | 119 | Pre-built binaries are available for: 120 | 121 | - Operating systems: Darwin (Apple), Linux 122 | - Architectures: x86_64 (amd64), arm64 123 | 124 | ### Installation Options 125 | 126 | You can install the latest version or specify a particular version: 127 | 128 | ```bash-vue 129 | # Install latest version 130 | bash -c "$(curl -sL https://docs.celestia.org/celestia-node.sh)" 131 | 132 | # Install specific version, Mainnet Beta in this example 133 | bash -c "$(curl -sL https://docs.celestia.org/celestia-node.sh)" -- -v {{mainnetVersions['node-latest-tag']}} 134 | ``` 135 | 136 | The script will: 137 | 138 | 1. Detect your system's operating system and architecture 139 | 2. Download the appropriate binary 140 | 3. Verify the checksum for security 141 | 4. Provide installation location options based on your environment: 142 | - If Go is installed: 143 | - Go bin directory (`$GOPATH/bin`) 144 | - System bin directory (`/usr/local/bin`) 145 | - Keep in current directory 146 | - If Go is not installed: 147 | - System bin directory (`/usr/local/bin`) 148 | - Keep in current directory 149 | 150 | Follow the instructions in the terminal output to choose your installation preferences. After installation, you can verify the setup by checking the version: 151 | 152 | ```bash 153 | celestia version && celestia --help 154 | ``` 155 | 156 | View [the script](https://github.com/celestiaorg/docs/tree/main/public/celestia-node.sh) to learn more about what it is doing. 157 | 158 | > **Note**: The script maintains a log file at `$HOME/celestia-node-temp/logfile.log` for troubleshooting purposes. 159 | 160 | ## Next steps 161 | 162 | First, we recommend [reading the overview](/how-to-guides/nodes-overview.md) 163 | of our node types, if you haven't yet. 164 | 165 | Now that you've installed Celestia Node, it's time to 166 | [pick your node type](/how-to-guides/decide-node.md) and run your node! 167 | 168 | If you're planning to run a light node, 169 | we recommend the [quick-start guide](/how-to-guides/quick-start.md). 170 | 171 | ## Upgrading your binary 172 | 173 | To upgrade your binary, you can install the latest version from the 174 | instructions above and restart your node. If you run into any issues, 175 | Refer to the [troubleshooting section](/how-to-guides/celestia-node-troubleshooting.md). 176 | -------------------------------------------------------------------------------- /how-to-guides/config-toml.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: A guide to the contents of the Config.toml file. 3 | --- 4 | 5 | # config.toml guide 6 | 7 | ## Pre-requisites 8 | 9 | Please, make sure that you have installed and initialized `celestia-node` 10 | 11 | ## Viewing the help menu 12 | 13 | In order to view all flags and their descriptions, use: 14 | 15 | ```bash 16 | celestia light start --help 17 | ``` 18 | 19 | ## Understanding config.toml 20 | 21 | After initialization, for any type of node, you will find a 22 | `config.toml` in the following path (default location): 23 | 24 | - `$HOME/.celestia-bridge/config.toml` for bridge node 25 | - `$HOME/.celestia-light/config.toml` for light node 26 | - `$HOME/.celestia-full/config.toml` for a full DA node 27 | 28 | Let's break down some of the most used sections. 29 | 30 | ### Core (Consensus) 31 | 32 | This section is needed for the Celestia bridge node. 33 | By default, `Remote = false`. Still for devnet, we are going 34 | to use the remote consensus node option and this can also be set 35 | by the command line flag `--core.remote`. 36 | 37 | ### P2P 38 | 39 | #### Bootstrap 40 | 41 | Bootstrappers help new nodes to find peers faster in the network. 42 | By default, the `Bootstrapper = false` and the `BootstrapPeers` is empty. 43 | If you want your node to be a bootstrapper, then activate `Bootstrapper = true`. 44 | `BootstrapPeers` are already provided by default during initialisation. 45 | If you want to add your own manually, you need to provide the 46 | multiaddresses of the peers. 47 | 48 | #### Mutual peers 49 | 50 | The purpose of this config is to set up a bidirectional communication. 51 | This is usually the case for Celestia bridge nodes. In addition, you 52 | need to change the field `PeerExchange` from false to true. 53 | 54 | ### Services 55 | 56 | #### TrustedHash and TrustedPeer 57 | 58 | `TrustedHash` is needed to properly initialize a Celestia bridge 59 | node with an already-running `Remote` Celestia consensus node. Celestia 60 | light node will take a genesis hash as the trusted one, if no hash 61 | is manually provided during initialization phase. 62 | 63 | `TrustedPeers` is the array of bridge nodes' peers that Celestia 64 | light node trusts. By default, bootstrap peers becomes trusted peers 65 | for Celestia light nodes if a user is not setting the trusted peer params 66 | in config file. 67 | 68 | Any Celestia bridge node can be a trusted peer for the light one. However, 69 | the light node by design can not be a trusted peer for another light node. 70 | -------------------------------------------------------------------------------- /how-to-guides/decide-node.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: Guide on helping you decide which type of node to run. 3 | --- 4 | 5 | # Deciding which node to run 6 | 7 | Now that you have installed the basic dependencies, 8 | you can start exploring which nodes to run! 9 | 10 | ## Light node 11 | 12 | It is highly recommended to 13 | get started with running a data availability [light node](/how-to-guides/light-node.md). 14 | 15 | You can also play around with the Data Availability API in 16 | [this tutorial for posting and retrieving data with a light node](/tutorials/node-tutorial.md). 17 | 18 | ### Other DA nodes 19 | 20 | Depending on your use case, you also may want to run a [bridge node](/how-to-guides/bridge-node.md) 21 | or a [full DA node](/how-to-guides/full-storage-node.md). 22 | 23 | ## Consensus node 24 | 25 | If you are looking to run a consensus node, please follow the 26 | [tutorial for running a consensus node](/how-to-guides/consensus-node.md). 27 | 28 | Note that running a validator means you must also run a bridge node, 29 | which is covered in [this section](/how-to-guides/bridge-node.md). 30 | -------------------------------------------------------------------------------- /how-to-guides/environment.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: Learn to set up your development environment to run Celestia software. 3 | --- 4 | 5 | # Development environment 6 | 7 | 8 | 9 | 15 | 16 | This page will go over setting up your development environment 17 | to run Celestia software. This environment can be used for development, building 18 | binaries, and running nodes. 19 | 20 | ## Supported architectures 21 | 22 | Celestia-app and celestia-node only officially support the following architectures: 23 | 24 | - linux/amd64 25 | - linux/arm64 26 | - darwin/amd64 (macOS Intel) 27 | - darwin/arm64 (macOS Apple Silicon) 28 | 29 | Only these four architectures are officially tested and supported. 30 | 31 | ## Install dependencies 32 | 33 | 1. If you are on Ubuntu, first update and upgrade your OS: 34 | 35 | ::: code-group 36 | 37 | ```bash [APT] 38 | sudo apt update && sudo apt upgrade -y 39 | ``` 40 | 41 | ```bash [YUM] 42 | sudo yum update 43 | ``` 44 | 45 | ::: 46 | 47 | 2. Install essential packages that are necessary to execute many tasks like 48 | downloading files, compiling, and monitoring the node: 49 | 50 | ::: code-group 51 | 52 | ```bash [APT] 53 | sudo apt install curl tar wget aria2 clang pkg-config libssl-dev jq build-essential \ 54 | git make ncdu -y 55 | ``` 56 | 57 | ```bash [YUM] 58 | sudo yum install curl tar wget aria2 clang pkg-config libssl-dev jq build-essential \ 59 | git make ncdu -y 60 | ``` 61 | 62 | ```bash [Mac] 63 | # these commands are for installing Homebrew, wget and jq 64 | # follow the instructions from the output after running this command 65 | /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" 66 | 67 | # then install wget & jq 68 | brew install wget && brew install jq 69 | ``` 70 | 71 | ::: 72 | 73 | ## Install Golang 74 | 75 | celestia-node is written in Golang so we must install Golang to build 76 | and run our node. 77 | 78 | 1. Set the version for your desired network: 79 | 80 | ::: code-group 81 | 82 | ```bash-vue [Mainnet Beta] 83 | ver="{{constants.golangNodeMainnet}}" 84 | ``` 85 | 86 | ```bash-vue [Mocha] 87 | ver="{{constants.golangNodeMocha}}" 88 | ``` 89 | 90 | ```bash-vue [Arabica] 91 | ver="{{constants.golangNodeArabica}}" 92 | ``` 93 | 94 | ::: 95 | 96 | 2. Download and install Golang: 97 | 98 | ::: code-group 99 | 100 | ```bash-vue [Ubuntu (AMD)] 101 | cd $HOME 102 | wget "https://golang.org/dl/go$ver.linux-amd64.tar.gz" 103 | sudo rm -rf /usr/local/go 104 | sudo tar -C /usr/local -xzf "go$ver.linux-amd64.tar.gz" 105 | rm "go$ver.linux-amd64.tar.gz" 106 | ``` 107 | 108 | ```bash-vue [Ubuntu (ARM)] 109 | cd $HOME 110 | wget "https://golang.org/dl/go$ver.linux-arm64.tar.gz" 111 | sudo rm -rf /usr/local/go 112 | sudo tar -C /usr/local -xzf "go$ver.linux-arm64.tar.gz" 113 | rm "go$ver.linux-arm64.tar.gz" 114 | ``` 115 | 116 | ```bash-vue [Mac (Apple)] 117 | cd $HOME 118 | wget "https://golang.org/dl/go$ver.darwin-arm64.tar.gz" 119 | sudo rm -rf /usr/local/go 120 | sudo tar -C /usr/local -xzf "go$ver.darwin-arm64.tar.gz" 121 | rm "go$ver.darwin-arm64.tar.gz" 122 | ``` 123 | 124 | ```bash-vue [Mac (Intel)] 125 | cd $HOME 126 | wget "https://golang.org/dl/go$ver.darwin-amd64.tar.gz" 127 | sudo rm -rf /usr/local/go 128 | sudo tar -C /usr/local -xzf "go$ver.darwin-amd64.tar.gz" 129 | rm "go$ver.darwin-amd64.tar.gz" 130 | ``` 131 | 132 | ::: 133 | 134 | 3. Add your `/usr/local/go/bin` directory to 135 | your `$PATH` if you have not already: 136 | 137 | ::: code-group 138 | 139 | ```bash [bash] 140 | echo "export PATH=$PATH:/usr/local/go/bin:$HOME/go/bin" >> $HOME/.bash_profile 141 | source $HOME/.bash_profile 142 | ``` 143 | 144 | ```bash [zsh] 145 | echo "export PATH=$PATH:/usr/local/go/bin:$HOME/go/bin" >> $HOME/.zshrc 146 | source $HOME/.zshrc 147 | ``` 148 | 149 | ::: 150 | 151 | ::: tip 152 | Use `echo $SHELL` to figure out what type of shell you are using! 153 | ::: 154 | 155 | 4. To verify that the correct version of Go was installed correctly run: 156 | 157 | ```bash 158 | go version 159 | ``` 160 | 161 | The output will show the version installed. 162 | -------------------------------------------------------------------------------- /how-to-guides/intro-to-op-stack.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: Learn about the integration of OP Stack with Celestia. 3 | prev: 4 | text: "How to run an Orbit full node and validator" 5 | link: "/how-to-guides/arbitrum-full-node" 6 | --- 7 | 8 | 9 | 10 | # Introduction to OP Stack integration 11 | 12 | [Optimism](https://optimism.io) is a low-cost and lightning-fast Ethereum 13 | L2 blockchain, built with [the OP Stack](https://stack.optimism.io/). 14 | 15 | [Celestia](https://celestia.org) is a modular consensus and data availability (DA) network, 16 | built to enable anyone to easily deploy their own blockchain with 17 | minimal overhead. 18 | 19 | Together, they allow developers to create rollups that 20 | post data to Celestia and settle on Ethereum. 21 | 22 | ## About the integration 23 | 24 | [Optimism](https://www.optimism.io/) uses Ethereum as 25 | a DA layer. Currently, settlement and DA for 26 | Optimism are on Ethereum, both onchain. `op-batcher` batches up 27 | rollup blocks and posts to Ethereum. 28 | 29 | The integration of OP Stack with Celestia underneath for DA 30 | allows rollup operators to reduce overhead that is associated with posting 31 | data as `calldata` on Ethereum. Instead, `op-batcher` batches up 32 | rollup blocks and posts them to Celestia's DA network. 33 | 34 | Data is managed in two ways. First, data is written 35 | to the data availability (DA) layer i.e. in this case Celestia, then the 36 | data commitment is written to the `op-batcher`. When reading `op-node` 37 | simply reads the data back from the DA layer by reading the 38 | data commitment from the `op-batcher` first, then reading the 39 | data from the DA layer using the data commitment. While 40 | previously `op-node` was reading from `calldata` on Ethereum, it now reads data from Celestia. 41 | 42 | There are a few tools involved in the data handling process. `op-batcher` 43 | batches up rollup blocks and posts them to Ethereum. `op-geth` handles 44 | execution, while `op-proposer` is responsible for state commitment 45 | submission. 46 | 47 | By using Celestia as a DA layer, existing L2s can switch from posting 48 | their data as `calldata` on Ethereum, to posting to Celestia. 49 | The commitment to the block is posted on Celestia, which is 50 | purpose-built for data availability. This is a more scalable than 51 | the traditional method of posting this data as `calldata` on monolithic chains. 52 | 53 | ### GitHub repository 54 | 55 | Find the 56 | [repository for this integration](https://github.com/celestiaorg/optimism/) 57 | at `https://github.com/celestiaorg/optimism`. 58 | 59 | :::warning 60 | This is a **beta integration** and we are working on resolving 61 | [open issues](https://github.com/celestiaorg/optimism/issues). 62 | ::: 63 | 64 | 83 | -------------------------------------------------------------------------------- /how-to-guides/local-devnet.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: Learn how to set up a local devnet with Celestia consensus and bridge nodes. 3 | --- 4 | 5 | # Local devnet setup 6 | 7 | This guide covers how to set up a local devnet with both consensus and bridge 8 | nodes for development and testing purposes. A local devnet allows you to run a 9 | complete Celestia network environment on your local machine. 10 | 11 | ## Prerequisites 12 | 13 | - [Install celestia-app](/how-to-guides/celestia-app.md) 14 | - [Install celestia-node](/how-to-guides/celestia-node.md) 15 | - [Install Docker and Docker Compose](https://docs.docker.com/get-docker) 16 | (for Docker setup) 17 | 18 | ## Script-based setup 19 | 20 | ### Single consensus node 21 | 22 | To start a local consensus node using the provided script: 23 | 24 | 1. Clone and build celestia-app: 25 | 26 | ```bash 27 | git clone https://github.com/celestiaorg/celestia-app.git 28 | cd celestia-app 29 | make install 30 | ``` 31 | 32 | 2. Run the single node script: 33 | 34 | ```bash 35 | ./scripts/single-node.sh 36 | ``` 37 | 38 | This script will: 39 | 40 | - Initialize a new chain with a single validator 41 | - Create a genesis file with pre-funded accounts 42 | - Start the consensus node 43 | - Make RPC endpoints available at `localhost:26657` 44 | 45 | ### Single consensus node + bridge node 46 | 47 | To set up both a consensus node and a bridge node together: 48 | 49 | 1. Follow the consensus node setup above 50 | 51 | 2. In a new terminal, run the bridge node script: 52 | 53 | ```bash 54 | ./scripts/single-bridge-node.sh 55 | ``` 56 | 57 | This will: 58 | 59 | - Start a bridge node that connects to your local consensus node 60 | - Enable data availability sampling 61 | - Make the bridge node API available at `localhost:26658` 62 | 63 | ## Docker setup 64 | 65 | For a containerized setup using Docker Compose, you can use a simplified 66 | configuration based on the Celestia ZKEVM IBC demo repository. 67 | 68 | 1. Create a `docker-compose.yml` file with the following content: 69 | 70 | ```yaml 71 | version: "3.8" 72 | services: 73 | celestia-validator: 74 | image: ghcr.io/celestiaorg/celestia-app:latest 75 | container_name: celestia-validator 76 | volumes: 77 | - celestia_validator_data:/home/celestia 78 | ports: 79 | - "9090:9090" 80 | - "26656:26656" 81 | - "26657:26657" 82 | command: | 83 | sh -c " 84 | celestia-appd init mynode --chain-id private && 85 | celestia-appd start 86 | " 87 | networks: 88 | - celestia-network 89 | 90 | celestia-bridge: 91 | image: ghcr.io/celestiaorg/celestia-node:latest 92 | container_name: celestia-bridge 93 | environment: 94 | - P2P_NETWORK=private 95 | volumes: 96 | - celestia_bridge_data:/home/celestia 97 | ports: 98 | - "26658:26658" 99 | command: > 100 | celestia bridge start 101 | --p2p.network private 102 | --core.ip celestia-validator 103 | --rpc.addr 0.0.0.0 104 | --rpc.port 26658 105 | depends_on: 106 | - celestia-validator 107 | networks: 108 | - celestia-network 109 | 110 | volumes: 111 | celestia_validator_data: 112 | celestia_bridge_data: 113 | 114 | networks: 115 | celestia-network: 116 | driver: bridge 117 | ``` 118 | 119 | 2. Start the services: 120 | 121 | ```bash 122 | docker-compose up -d 123 | ``` 124 | 125 | 3. Check the status: 126 | 127 | ```bash 128 | docker-compose ps 129 | docker-compose logs celestia-validator 130 | docker-compose logs celestia-bridge 131 | ``` 132 | 133 | ## Default endpoints 134 | 135 | Once your local devnet is running, you can access these endpoints: 136 | 137 | | Service | Endpoint | 138 | | --------------- | ------------------------ | 139 | | Consensus RPC | `http://localhost:26657` | 140 | | Consensus gRPC | `http://localhost:9090` | 141 | | Consensus P2P | `http://localhost:26656` | 142 | | Bridge node API | `http://localhost:26658` | 143 | 144 | ## Testing your setup 145 | 146 | You can test that your local devnet is working by: 147 | 148 | 1. Checking node status: 149 | 150 | ```bash 151 | curl http://localhost:26657/status 152 | ``` 153 | 154 | 2. Querying the latest block: 155 | 156 | ```bash 157 | curl http://localhost:26657/block 158 | ``` 159 | 160 | 3. For bridge nodes, check the DA network info: 161 | 162 | ```bash 163 | curl http://localhost:26658/head 164 | ``` 165 | 166 | ## Stopping the devnet 167 | 168 | ### Stopping script-based setup 169 | 170 | Stop the processes with `Ctrl+C` in each terminal. 171 | 172 | ### Stopping Docker setup 173 | 174 | ```bash 175 | docker-compose down 176 | ``` 177 | 178 | To also remove the volumes: 179 | 180 | ```bash 181 | docker-compose down -v 182 | ``` 183 | 184 | ## Next steps 185 | 186 | With your local devnet running, you can: 187 | 188 | - [Submit blob data](/how-to-guides/submit-data.md) 189 | - Test rollup integrations 190 | - Develop applications using the [Celestia Node API](/tutorials/node-api.md) 191 | - Practice validator operations without risking real tokens 192 | -------------------------------------------------------------------------------- /how-to-guides/multiaccounts.md: -------------------------------------------------------------------------------- 1 | # MultiAccounts feature for blobs submission 2 | 3 | ## Overview 4 | 5 | 6 | 7 | 10 | 11 | By default, a celestia-node creates a key named `my_celes_key` during 12 | initialization. This document explains how to run a node with a different 13 | default key name and how to submit blobs using different signers. 14 | 15 | ## Running a node with a different default key name 16 | 17 | To start a Celestia node with a different default key name, use the following 18 | command: 19 | 20 | ```sh-vue 21 | celestia light start --core.ip consensus.celestia-{{constants.arabicaChainId}}.com \ 22 | --core.port 9090 --p2p.network=arabica --keyring.keyname testKey 23 | ``` 24 | 25 | In this example, `testKey` becomes the default node key, and the 26 | node's address will change accordingly. 27 | 28 | ## Submitting blobs with a different signer/key name 29 | 30 | ### Option 1: Submit passing key name 31 | 32 | You can submit a blob by specifying a different key name: 33 | 34 | ```sh 35 | celestia blob submit 0x42690c204d39600fddd3 'gm' --key.name testKey2 36 | ``` 37 | 38 | This transaction will be signed by the address associated with `testKey2`. 39 | 40 | ### Option 2: Submit passing signer address 41 | 42 | Alternatively, you can submit a blob by specifying the signer's address: 43 | 44 | ```sh 45 | celestia blob submit 0x42690c204d39600fddd3 'gm' --signer $SIGNER_ADDRESS 46 | ``` 47 | 48 | Both options achieve the same result but use different inputs. The 49 | `testKey2` points to `SIGNER_ADDRESS` in the KeyStore. 50 | 51 | ## Key management 52 | 53 | All keys and addresses must be added to the KeyStore. To create a new key, 54 | use the [`cel-key` library](https://github.com/celestiaorg/celestia-node/blob/main/cmd/cel-key/main.go): 55 | 56 | ### Creating a new key 57 | 58 | ```sh 59 | ./cel-key add testKey --keyring-backend test \ 60 | --node.type light --p2p.network arabica 61 | ``` 62 | 63 | ### Importing an existing key 64 | 65 | ```sh 66 | ./cel-key import 67 | ``` 68 | 69 | Learn more on the 70 | [Create a wallet with celestia-node](/tutorials/celestia-node-key.md#create-a-wallet-with-celestia-node) 71 | page. 72 | 73 | ## Optional flags for write transactions 74 | 75 | All other flags are now optional for all write transactions. This 76 | means you don't have to specify gas/fee parameters each time. 77 | The configuration can handle it for you automatically. 78 | 79 | The default configuration applies to all write transactions, 80 | including those in the [state module](https://node-rpc-docs.celestia.org/#state) 81 | and [blob.Submit](https://node-rpc-docs.celestia.org/#blob.Submit). 82 | This simplifies the process of submitting transactions and 83 | reduces the need for manual input. 84 | 85 | For reference, see the: 86 | 87 | - [Transaction configuration](https://github.com/celestiaorg/celestia-node/blob/87e2802b687065055e117b4ed2a0128d0666587d/state/tx_config.go#L35) 88 | - [State module command implementation](https://github.com/celestiaorg/celestia-node/blob/87e2802b687065055e117b4ed2a0128d0666587d/nodebuilder/state/cmd/state.go#L420) 89 | -------------------------------------------------------------------------------- /how-to-guides/nitro-local.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: How to get started with local development on the Arbitrum Nitro stack. 3 | --- 4 | 5 | # Quickstart: Run a local devnet 6 | 7 | 1. Install docker and docker compose. 8 | 1. Clone [@celestiaorg/nitro](https://github.com/celestiaorg/nitro.git): 9 | 10 | ``` 11 | git clone -b release --recurse-submodules https://github.com/celestiaorg/nitro.git 12 | git checkout v3.2.5 && cd /nitro/nitro-testnode 13 | ``` 14 | 15 | 1. `./celestia-start.sh` 16 | 1. Some useful optional commands to use with the start script: 17 | - `--validate` (heavy computation, validates all blocks in WASM) 18 | - `--anytrsut` (launches anytrust DAC locally, useful to test anytrust fallbacks) 19 | 20 | ## Helper scripts 21 | 22 | The repository includes a set of helper scripts for basic actions like funding accounts or bridging funds. You can see a list of the available scripts by running: 23 | 24 | ```bash 25 | ./test-node.bash script --help 26 | ``` 27 | 28 | If you want to see information of a particular script, you can add the name of the script to the help command. 29 | 30 | ```bash 31 | ./test-node.bash script send-l1 --help 32 | ``` 33 | 34 | Here's an example of how to run the script that funds an address on L2. Replace`0x11223344556677889900` with the address you want to fund. 35 | 36 | `./test-node.bash script send-l2 --to address_0x11223344556677889900 --ethamount 5` 37 | 38 | ## Default endpoints and addresses 39 | 40 | Node RPC endpoints are available at: 41 | 42 | | Node | Chain id | RPC endpoint | 43 | | --------------------- | -------- | ------------------------------------------------- | 44 | | L1 geth devnet | 1337 | `http://localhost:8545` | 45 | | L2 nitro devnet | 412346 | `http://localhost:8547` and `ws://localhost:8548` | 46 | | L3 nitro (if enabled) | 333333 | `http://localhost:3347` | 47 | | Celestia DA server | | `http://localhost:9875` | 48 | | Anytrust | | `http://localhost:9876` | 49 | | Celestia Node | | `http://localhost:26658` | 50 | -------------------------------------------------------------------------------- /how-to-guides/nodes-overview.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: An overview on how to participate in the Celestia network. 3 | --- 4 | 5 | # Overview to running nodes on Celestia 6 | 7 | There are many ways you can participate in the Celestia 8 | [networks](/how-to-guides/participate.md). 9 | 10 | Celestia node operators can run several options on the network. 11 | 12 | Consensus: 13 | 14 | - [Validator node](/how-to-guides/validator-node.md): 15 | This type of node participates 16 | in consensus by producing and voting on blocks. 17 | - [Consensus node](/how-to-guides/consensus-node.md): A celestia-app full node 18 | to sync blockchain history. 19 | 20 | Data Availability: 21 | 22 | - [Bridge node](/how-to-guides/bridge-node.md): This node bridges blocks between the 23 | Data-Availability network and the Consensus network. 24 | - [Full storage node](/how-to-guides/full-storage-node.md): This node stores all 25 | the data but does not connect to Consensus. 26 | - [Light node](/how-to-guides/light-node.md): Light clients conduct data availability 27 | sampling on the Data Availability network. 28 | 29 | You can learn more about how to set up each different node by going through 30 | each tutorial guide. 31 | 32 | ## Recommended Celestia node requirements 33 | 34 | ## Data availability nodes 35 | 36 | ### Non-archival data availability nodes 37 | 38 | | Node type | Memory | CPU | Disk | Bandwidth | 39 | | ----------------- | ---------- | ----------- | ---------- | --------- | 40 | | Light node | 500 MB RAM | Single core | 100 GB SSD | 56 Kbps | 41 | | Bridge node | 64 GB RAM | 8 cores | 5 TiB NVME | 1 Gbps | 42 | | Full storage node | 64 GB RAM | 8 cores | 5 TiB NVME | 1 Gbps | 43 | 44 | ### Archival data availability nodes 45 | 46 | | Node type | Memory | CPU | Disk | Bandwidth | 47 | | ----------------- | ---------- | ----------- | ---------- | --------- | 48 | | Light node | 500 MB RAM | Single core | 100 GB SSD | 56 Kbps | 49 | | Bridge node | 64 GB RAM | 8 cores | 6 TiB NVME | 1 Gbps | 50 | | Full storage node | 64 GB RAM | 8 cores | 6 TiB NVME | 1 Gbps | 51 | 52 | ### Consensus nodes 53 | 54 | #### Non-archival consensus nodes 55 | 56 | | Node type | Memory | CPU | Disk | Bandwidth | 57 | | -------------- | --------- | ------- | ---------- | --------- | 58 | | Validator | 24 GB RAM | 8 cores | 3 TiB NVME | 1 Gbps | 59 | | Consensus node | 24 GB RAM | 8 cores | 3 TiB NVME | 1 Gbps | 60 | 61 | #### Archival consensus nodes 62 | 63 | | Node type | Memory | CPU | Disk | Bandwidth | 64 | | -------------- | --------- | ------- | ---------- | --------- | 65 | | Consensus node | 64 GB RAM | 8 cores | 6 TiB NVME | 1 Gbps | 66 | 67 | Please provide any feedback on the tutorials and guides. If you notice 68 | a bug or issue, feel free to make a pull request or write up a Github 69 | issue! 70 | -------------------------------------------------------------------------------- /how-to-guides/optimism.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: Start your own rollup with op-plasma-celestia and roll-op. 3 | next: 4 | text: "Introduction to Blobstream rollups" 5 | link: "/how-to-guides/blobstream-rollups" 6 | --- 7 | 8 | # Run an OP Stack rollup with Celestia underneath 9 | 10 | 11 | 14 | 15 | This guide will show you how to run your own OP Stack devnet and testnet that posts data to Celestia's Mocha testnet using [roll-op](https://github.com/celestiaorg/roll-op) and [op-plasma-celestia](https://github.com/celestiaorg/op-plasma-celestia). 16 | 17 | The roll-op tool is used to deploy and manage the OP Stack rollup environment, including the rollup, batcher, and other components. While the op-plasma-celestia integration allows the OP Stack to use Celestia as the data availability (DA) layer. 18 | 19 | This guide is in two parts: 20 | 21 | - First, you'll spin up a mock L1 environment and deploy a devnet that posts data to the Mocha testnet. 22 | - In the second part, you'll deploy a testnet that posts data to the Mocha testnet, but this time on a real L1 environment; the Ethereum Sepolia testnet. This will involve setting up a configuration file with the necessary details like Sepolia chain ID, RPC URL, and your deployment keys. 23 | 24 | After successful deployments, you'll be able to observe data blobs being successfully submitted to the Mocha testnet in the logs, as well as some activity on your rollup account on [Celenium](https://celenium.io). 25 | 26 | If you don't have devops experience and would like to use a Rollups as a Service (RaaS) provider, see the RaaS category in the menu. 27 | 28 | This guide is also available on [YouTube](https://www.youtube.com/watch?v=lOLw4uLX644) if you'd like to follow along with a video. 29 | 30 | ## Dependency setup 31 | 32 | - [celestia-node](/how-to-guides/celestia-node.md) 33 | 34 | ### Setting up your light node 35 | 36 | Sync and fund a Celestia light node. The light node must be **fully synced** and **funded** for you to be able to submit and retrieve `PayForBlobs` to Mocha Testnet. This allows your rollup to post and retrieve data without any errors. 37 | 38 | In order to mount existing data, you must have a node store that is in the default directory: 39 | 40 | ::: code-group 41 | 42 | ```bash-vue [Mocha] 43 | $HOME/.celestia-light-{{constants.mochaChainId}} 44 | ``` 45 | 46 | ```bash-vue [Mainnet Beta] 47 | $HOME/.celestia-light 48 | ``` 49 | 50 | ```bash-vue [Arabica] 51 | $HOME/.celestia-light-{{constants.arabicaChainId}} 52 | ``` 53 | 54 | ::: 55 | 56 | By default, the node will run with the account named `my_celes_key` on Mocha. This is the account that needs to be funded. 57 | 58 | ::: tip 59 | Unless you changed your configuration, you won't have to change anything. 😎 60 | ::: 61 | 62 | ## Deploying a devnet to Mocha 63 | 64 | See [the Alt-DA x Celestia README](https://github.com/celestiaorg/op-plasma-celestia/blob/main/README.md) for instructions on [how to deploy a Devnet](https://github.com/celestiaorg/op-plasma-celestia/blob/main/README.md#devnet). 65 | 66 | :::tip TIP for macOS users 67 | If you are on macOS, you will need to run a `venv` before starting `roll-op`. 68 | 69 | ```sh 70 | cd $HOME/roll-op 71 | python3 -m venv ./venv 72 | source ./venv/bin/activate 73 | ``` 74 | 75 | ::: 76 | 77 | Congrats! Your devnet is running on a mock EVM chain and Celestia Mocha. 78 | 79 | ## Deploying a testnet to an L1 (or L2) and Mocha 80 | 81 | See [the Alt-DA x Celestia README](https://github.com/celestiaorg/op-plasma-celestia/blob/main/README.md) for instructions on [how to deploy a Testnet](https://github.com/celestiaorg/op-plasma-celestia/blob/main/README.md#testnet). 82 | 83 | :::tip 84 | If you are using a public RPC for your EVM chain, you should enable `deploy_slowly = true` in your `config.toml`. If you still have issues, we recommend running the 85 | integration with a high-availability, paid endpoint. 86 | ::: 87 | 88 | When you are deploying to a live EVM network, pay attention and modify the configuration to post to non-Sepolia EVM chains. 89 | 90 | Here is an example: 91 | 92 | ```toml 93 | # Chain ID of your rollup 94 | l2_chain_id = 1117733 95 | 96 | # Sepolia Ethereum 97 | l1_chain_id = 11155111 98 | l1_rpc_url = "https://ethereum-sepolia-rpc.publicnode.com" 99 | 100 | ## Avoid issues with public RPC 101 | deploy_slowly = true 102 | 103 | ## Keys 104 | contract_deployer_account = "0xaddress" 105 | contract_deployer_key = "privatekey" 106 | batcher_account = "0xaddress" 107 | batcher_key = "privatekey" 108 | proposer_account = "0xaddress" 109 | proposer_key = "privatekey" 110 | admin_account = "0xaddress" 111 | admin_key = "privatekey" 112 | p2p_sequencer_account = "0xaddress" 113 | p2p_sequencer_key = "privatekey" 114 | ``` 115 | 116 | Your `0xaddress` key must also be funded with testnet ETH. We recommend at least 10 SepoliaETH to get your chain started, but you will need more to keep it running longer. 117 | 118 | ## Congratulations 119 | 120 | Congrats! You now have an OP Stack rollup running with Celestia underneath. 121 | 122 | You can [learn more about Alt-DA in Optimism docs](https://docs.optimism.io/builders/chain-operators/features/alt-da-mode#setup-your-da-server). 123 | -------------------------------------------------------------------------------- /how-to-guides/participate.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | # Participate in the Celestia networks 4 | 5 | 6 | 7 | 13 | 14 | ## Mainnet Beta 15 | 16 | Celestia’s [Mainnet Beta](/how-to-guides/mainnet.md) is the production network 17 | for deploying Mainnet Beta rollups and applications. This marks the 18 | culmination of years of development and community testing. While 19 | the network is stable and continues to receive updates, it remains 20 | experimental and users may experience occasional instability or 21 | reduced performance. 22 | 23 | ### Compatible software versions for Mainnet Beta 24 | 25 | 26 | 27 | ## Testnets 28 | 29 | Celestia currently has two existing testnets that you can participate in: 30 | 31 | ### Arabica Devnet 32 | 33 | [Arabica devnet](/how-to-guides/arabica-devnet.md) is a devnet focused on developers who 34 | want to deploy sovereign rollups on the latest changes from Celestia's codebase. 35 | Arabica will be updated frequently and might be unstable at times given new updates. 36 | Validators won't be able to validate on Arabica as it is not designed for 37 | validators to participate. 38 | 39 | #### Compatible software versions for Arabica devnet 40 | 41 | 42 | 43 | ### Mocha testnet 44 | 45 | [Mocha testnet](/how-to-guides/mocha-testnet.md) is a testnet focused on enabling validators 46 | to test out their infrastructure by running nodes connected to the network. Developers 47 | can also deploy sovereign rollups on Mocha, it just will always be behind Arabica 48 | as Mocha upgrades are slower given they need to be done via breaking network upgrades 49 | in coordination with the validator community on Mocha. 50 | 51 | ### Compatible software versions for Mocha testnet 52 | 53 | 54 | 55 | ## Network upgrades 56 | 57 | There are a few ways to stay informed about network upgrades: 58 | 59 | - Telegram [announcement channel](https://t.me/+smSFIA7XXLU4MjJh) 60 | - Discord [Mainnet Beta announcements](https://discord.com/channels/638338779505229824/1169237690114388039) 61 | - Discord [Mocha announcements](https://discord.com/channels/638338779505229824/979037494735691816) 62 | 63 | See the [network upgrade process page](/how-to-guides/network-upgrade-process.md) to learn more 64 | about specific upgrades like the [Ginger network upgrade](/how-to-guides/network-upgrade-process.md#ginger-network-upgrade). 65 | -------------------------------------------------------------------------------- /how-to-guides/sp1-blobstream-deploy.md: -------------------------------------------------------------------------------- 1 | --- 2 | next: 3 | text: "Overview of Blobstream X" 4 | link: "/how-to-guides/blobstreamx" 5 | --- 6 | 7 | # New SP1 Blobstream deployments 8 | 9 | This document provides instructions for deploying SP1 Blobstream to a new chain. 10 | 11 | [SP1 Blobstream](https://github.com/succinctlabs/sp1-blobstream) is the latest implementation of Blobstream 12 | in Rust using the [SP1](https://github.com/succinctlabs/sp1) zkVM. 13 | 14 | ## Deploying the contracts 15 | 16 | To deploy SP1 Blobstream to a new chain, follow these steps: 17 | 18 | 1. Clone the sp1-blobstream repository: 19 | 20 | ```shell 21 | git clone https://github.com/succinctlabs/sp1-blobstream 22 | cd sp1-blobstream 23 | ``` 24 | 25 | 2. Follow the deployment instructions in the 26 | [sp1-blobstream README](https://github.com/succinctlabs/sp1-blobstream?tab=readme-ov-file#deployment). 27 | 28 | 3. If you're deploying on a chain where there isn't a canonical verifier listed in the 29 | [deployed contracts](/how-to-guides/blobstream#deployed-contracts), you'll need to: 30 | 31 | a. Deploy your own SP1 Verifier from the [sp1-contracts](https://github.com/succinctlabs/sp1-contracts) matching your `sp1-sdk` version. 32 | b. Set the `SP1_VERIFIER_ADDRESS` in your `.env` file to the address of your deployed verifier. 33 | 34 | 4. To run the prover: 35 | 36 | - For local proving, set `SP1_PROVER=local` in your environment. 37 | - To use the Succinct Proving Network for remote proving, set `SP1_PROVER=network`. 38 | - We recommend an instance with 64 vCPU and 128GB of RAM for local proving. 39 | 40 | Note: Any whitelisting for custom provers would need to be implemented in the application's smart contracts (e.g., by using an approvedProvers mapping). 41 | -------------------------------------------------------------------------------- /how-to-guides/systemd.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: Learn how to setup your node as a background process with SystemD. 3 | --- 4 | 5 | # Setting up your node as a background process with SystemD 6 | 7 | SystemD is a daemon service useful for running applications as background 8 | processes. 9 | 10 | ## Consensus nodes 11 | 12 | If you are running a validator or consensus node, here are 13 | the steps to setting up `celestia-appd` as a background process. 14 | 15 | ### Start the celestia-app with SystemD 16 | 17 | SystemD is a daemon service useful for running applications as background 18 | processes. 19 | 20 | Create Celestia-App systemd file: 21 | 22 | ```sh 23 | sudo tee </dev/null /etc/systemd/system/celestia-appd.service 24 | [Unit] 25 | Description=celestia-appd Cosmos daemon 26 | After=network-online.target 27 | 28 | [Service] 29 | User=$USER 30 | ExecStart=$(which celestia-appd) start 31 | Restart=on-failure 32 | RestartSec=3 33 | LimitNOFILE=65535 34 | 35 | [Install] 36 | WantedBy=multi-user.target 37 | EOF 38 | ``` 39 | 40 | If the file was created successfully you will be able to see its content: 41 | 42 | ```sh 43 | cat /etc/systemd/system/celestia-appd.service 44 | ``` 45 | 46 | Enable and start `celestia-appd` daemon: 47 | 48 | ```sh 49 | sudo systemctl enable celestia-appd 50 | sudo systemctl start celestia-appd 51 | ``` 52 | 53 | Check if daemon has been started correctly: 54 | 55 | ```sh 56 | sudo systemctl status celestia-appd 57 | ``` 58 | 59 | Check daemon logs in real time: 60 | 61 | ```sh 62 | sudo journalctl -u celestia-appd.service -f 63 | ``` 64 | 65 | To check if your node is in sync before going forward: 66 | 67 | ```sh 68 | curl -s localhost:26657/status | jq .result | jq .sync_info 69 | ``` 70 | 71 | Make sure that you have `"catching_up": false`, otherwise leave it running 72 | until it is in sync. 73 | 74 | ## Data availability nodes 75 | 76 | ### Celestia full storage node 77 | 78 | Create Celestia full storage node systemd file: 79 | 80 | ```sh 81 | sudo tee </dev/null /etc/systemd/system/celestia-full.service 82 | [Unit] 83 | Description=celestia-full Cosmos daemon 84 | After=network-online.target 85 | 86 | [Service] 87 | User=$USER 88 | ExecStart=$(which celestia) full start 89 | Restart=on-failure 90 | RestartSec=3 91 | LimitNOFILE=1400000 92 | 93 | [Install] 94 | WantedBy=multi-user.target 95 | EOF 96 | ``` 97 | 98 | If the file was created successfully you will be able to see its content: 99 | 100 | ```sh 101 | cat /etc/systemd/system/celestia-full.service 102 | ``` 103 | 104 | Enable and start celestia-full daemon: 105 | 106 | ```sh 107 | sudo systemctl enable celestia-full 108 | sudo systemctl start celestia-full && sudo journalctl -u \ 109 | celestia-full.service -f 110 | ``` 111 | 112 | You should be seeing logs coming through of the full storage node syncing. 113 | 114 | ### Celestia bridge node 115 | 116 | Create Celestia Bridge systemd file: 117 | 118 | ```sh 119 | sudo tee </dev/null /etc/systemd/system/celestia-bridge.service 120 | [Unit] 121 | Description=celestia-bridge Cosmos daemon 122 | After=network-online.target 123 | 124 | [Service] 125 | User=$USER 126 | ExecStart=$(which celestia) bridge start 127 | Restart=on-failure 128 | RestartSec=3 129 | LimitNOFILE=1400000 130 | 131 | [Install] 132 | WantedBy=multi-user.target 133 | EOF 134 | ``` 135 | 136 | If the file was created successfully you will be able to see its content: 137 | 138 | ```sh 139 | cat /etc/systemd/system/celestia-bridge.service 140 | ``` 141 | 142 | Enable and start celestia-bridge daemon: 143 | 144 | ```sh 145 | sudo systemctl enable celestia-bridge 146 | sudo systemctl start celestia-bridge && sudo journalctl -u \ 147 | celestia-bridge.service -f 148 | ``` 149 | 150 | Now, the Celestia bridge node will start syncing headers and storing blocks 151 | from `celestia-app`. 152 | 153 | :::tip NOTE 154 | At startup, we can see the `multiaddress` from Celestia bridge node. 155 | This is **needed for future light node** connections and communication between 156 | Celestia Bridge Nodes 157 | ::: 158 | 159 | Example: 160 | 161 | ```sh 162 | NODE_IP=] 163 | /ip4/$NODE_IP/tcp/2121/p2p/12D3KooWD5wCBJXKQuDjhXFjTFMrZoysGVLtVht5hMoVbSLCbV22 164 | ``` 165 | 166 | You should be seeing logs coming through of the bridge node syncing. 167 | 168 | ### Celestia light node 169 | 170 | Start the light node as daemon process in the background 171 | 172 | 173 | 174 | ```sh 175 | sudo tee </dev/null /etc/systemd/system/celestia-lightd.service 176 | [Unit] 177 | Description=celestia-lightd light node 178 | After=network-online.target 179 | 180 | [Service] 181 | User=$USER 182 | ExecStart=$(which celestia) light start --core.ip --core.port 183 | Restart=on-failure 184 | RestartSec=3 185 | 186 | [Install] 187 | WantedBy=multi-user.target 188 | EOF 189 | ``` 190 | 191 | 192 | 193 | If the file was created successfully you will be able to see its content: 194 | 195 | ```sh 196 | cat /etc/systemd/system/celestia-lightd.service 197 | ``` 198 | 199 | Enable and start celestia-lightd daemon: 200 | 201 | ```sh 202 | sudo systemctl enable celestia-lightd 203 | sudo systemctl start celestia-lightd 204 | ``` 205 | 206 | Check if daemon has been started correctly: 207 | 208 | ```sh 209 | sudo systemctl status celestia-lightd 210 | ``` 211 | 212 | Check daemon logs in real time: 213 | 214 | ```sh 215 | sudo journalctl -u celestia-lightd.service -f 216 | ``` 217 | 218 | Now, the Celestia light node will start syncing headers. 219 | After sync is finished, light node will do Data Availability 220 | Sampling (DAS) from the bridge node. 221 | -------------------------------------------------------------------------------- /how-to-guides/transaction-resubmission.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: This is a guide on transaction resubmission on Celestia. 3 | --- 4 | 5 | # Transaction resubmission 6 | 7 | In cases where transactions are not included within a 75-second window, 8 | resubmission is necessary. This is especially important during network 9 | congestion, as transactions with relatively low fees may not be processed 10 | even after the network clears up. 11 | 12 | Regardless of whether they originate from celestia-app or celestia-node, 13 | transactions will not be re-gossiped, except in the presence of a new peer. 14 | 15 | If you are running a production application on Celestia, it is recommended 16 | to use a high-availability, production 17 | RPC provider for [Mainnet Beta](/how-to-guides/mainnet.md#production-rpc-endpoints),[Mocha](/how-to-guides/mocha-testnet.md#production-rpc-endpoints), 18 | or [Arabica](/how-to-guides/arabica-devnet.md#production-rpc-endpoints). 19 | 20 | ## Monitoring and resubmission 21 | 22 | Monitor the status of your transactions. If a transaction is not included within 23 | a 75-second window, it should be resubmitted. This can be done manually or 24 | through automated processes. 25 | 26 | Changes introduced in [celestiaorg/celestia-core#1089](https://github.com/celestiaorg/celestia-core/pull/1089) 27 | may affect transaction gossiping and inclusion speed. 28 | 29 | ## Notes 30 | 31 | - All transactions, regardless of their origin, are subject to being sorted and 32 | pruned based on fees. 33 | - It is the user or developer's responsibility to monitor and possibly resubmit 34 | transactions if they are not included in a 75-second window. 35 | -------------------------------------------------------------------------------- /index.md: -------------------------------------------------------------------------------- 1 | --- 2 | # https://vitepress.dev/reference/default-theme-home-page 3 | layout: home 4 | titleTemplate: ":title" 5 | 6 | hero: 7 | name: "Celestia" 8 | text: "Build whatever" 9 | tagline: Celestia is the modular blockchain powering unstoppable applications with full-stack control. 10 | image: 11 | src: /Blobspace.png 12 | alt: Celestia 13 | actions: 14 | - theme: brand 15 | text: Quick start 16 | link: /how-to-guides/quick-start 17 | - theme: alt 18 | text: Introduction 19 | link: /learn/how-celestia-works/overview 20 | 21 | features: 22 | - title: Learn 23 | details: Celestia allows you to deploy your own blockchain in minutes, as easily as a smart contract. 24 | link: /learn/how-celestia-works/overview 25 | icon: 🏗️ 26 | - title: How-to guides 27 | details: Explore step-by-step guides for running a node, posting data blobs, building applications and sovereign rollups on Celestia. 28 | link: /how-to-guides/quick-start 29 | icon: 📈 30 | - title: Tutorials 31 | details: Access tutorials for interacting with Celestia, starting with celestia-node through the node API. 32 | link: /tutorials/node-api 33 | icon: ⚙️ 34 | - title: Community 35 | details: Join the Celestia discord to connect, collaborate, and contribute to the future of modular blockchains. 36 | link: https://discord.gg/celestiacommunity 37 | icon: 🏰 38 | --- 39 | -------------------------------------------------------------------------------- /learn/how-celestia-works/monolithic-vs-modular.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: Comparison between monolithic and modular blockchains. 3 | --- 4 | 5 | # Monolithic vs. modular blockchains 6 | 7 | Blockchains instantiate [replicated state machines](https://dl.acm.org/doi/abs/10.1145/98163.98167): 8 | the nodes in a permissionless distributed network apply an ordered sequence 9 | of deterministic transactions to an initial state resulting in a common 10 | final state. 11 | 12 | In other words, this means that nodes in a network all follow 13 | the same set of rules (_i.e._, an ordered sequence of transactions) to go from a 14 | starting point (_i.e._, an initial state) to an ending point 15 | (_i.e._, a common final state). This process ensures that all 16 | nodes in the network agree on the final state 17 | of the blockchain, even though they operate independently. 18 | 19 | This means blockchains 20 | require the following four functions: 21 | 22 | - **Execution** entails executing transactions that update the state correctly. 23 | Thus, execution must ensure that only valid transactions are executed, _i.e._, 24 | transactions that result in valid state machine transitions. 25 | - **Settlement** entails an environment for execution layers to verify proofs, 26 | resolve fraud disputes, and bridge between other execution layers. 27 | - **Consensus** entails agreeing on the order of the transactions. 28 | - **Data Availability** (DA) entails making the transaction data available. 29 | Note that execution, settlement, and consensus require DA. 30 | 31 | Traditional blockchains, _i.e._ _monolithic blockchains_, implement all four 32 | functions together in a single base consensus layer. The problem with 33 | monolithic blockchains is that the consensus layer must perform numerous 34 | different tasks, and it cannot be optimized for only one of these functions. 35 | As a result, the monolithic paradigm limits the throughput of the system. 36 | 37 | ![Modular VS Monolithic](/img/learn/monolithic-modular.png) 38 | 39 | As a solution, modular blockchains decouple these functions among 40 | multiple specialized layers as part of a modular stack. Due to the 41 | flexibility that specialization provides, there are many possibilities 42 | in which that stack can be arranged. For example, one such arrangement 43 | is the separation of the four functions into three specialized layers. 44 | 45 | The base layer consists of DA and consensus and thus, is referred to 46 | as the Consensus and DA layer (or for brevity, the DA layer), while both 47 | settlement and execution are moved on top in their own layers. As a result, 48 | every layer can be specialized to optimally perform only its function, and thus, 49 | increase the throughput of the system. Furthermore, this modular paradigm 50 | enables multiple execution layers, _i.e._, 51 | [rollups](https://vitalik.eth.limo/general/2021/01/05/rollup.html), to use the 52 | same settlement and DA layers. 53 | -------------------------------------------------------------------------------- /learn/how-celestia-works/overview.md: -------------------------------------------------------------------------------- 1 | # Introduction 2 | 3 | Celestia is a modular 4 | [data availability network](https://blog.celestia.org/celestia-a-scalable-general-purpose-data-availability-layer-for-decentralized-apps-and-trust-minimized-sidechains) 5 | that securely scales with the number of users, making it easy for anyone 6 | to launch their own blockchain. 7 | 8 | Celestia enables the next generation of scalable blockchain architectures - 9 | [modular blockchains](https://celestia.org/learn). Celestia scales by 10 | [decoupling execution from consensus](https://arxiv.org/abs/1905.09274) and 11 | introducing a new primitive, 12 | [data availability sampling](https://arxiv.org/abs/1809.09044). 13 | 14 | The former entails that Celestia is only responsible for ordering 15 | transactions and guaranteeing their data availability; this is 16 | similar to [reducing consensus to atomic broadcast](https://en.wikipedia.org/wiki/Atomic_broadcast#Equivalent_to_Consensus). 17 | 18 | The latter provides an efficient solution to the 19 | [data availability problem](https://coinmarketcap.com/alexandria/article/what-is-data-availability) 20 | by only requiring resource-limited light nodes to sample a 21 | small number of random shares from each block to verify data availability. 22 | 23 | Interestingly, more light nodes that participate in sampling 24 | increases the amount of data that the network can safely handle, 25 | enabling the block size to increase without equally increasing the 26 | cost to verify the chain. 27 | -------------------------------------------------------------------------------- /learn/how-celestia-works/transaction-lifecycle.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: Learn what is the lifecycle of a celestia-app transaction. 3 | --- 4 | 5 | # The lifecycle of a celestia-app transaction 6 | 7 | Users request the celestia-app to make data available by 8 | sending `PayForBlobs` transactions. Every such transaction consists 9 | of the identity of the sender, the data to be made available, also 10 | referred to as the message, the data size, the namespace, and 11 | a signature. Every block producer batches multiple `PayForBlobs` 12 | transactions into a block. 13 | 14 | Before proposing the block though, the producer passes it to the 15 | state machine via ABCI++, where each `PayForBlobs` transaction is 16 | split into a namespaced message (denoted by `Msg` in the figure below), 17 | i.e., the data together with the namespace ID, and an executable 18 | transaction (denoted by `e-Tx` in the figure below) that does not 19 | contain the data, but only a commitment that can be used at a later 20 | time to prove that the data was indeed made available. 21 | 22 | Thus, the block data consists of data partitioned into namespaces 23 | and executable transactions. Note that only these transactions are 24 | executed by the Celestia state machine once the block is committed. 25 | 26 | ![Lifecycle of a celestia-app Transaction](/img/learn/tx-lifecycle.png) 27 | 28 | Next, the block producer adds to the block header a commitment 29 | of the block data. As 30 | [described in the "Celestia's data availability layer" page](/how-to-guides/data-availability-layer.md), 31 | the commitment is the Merkle root of the $4k$ intermediate Merkle roots 32 | (i.e., one for each row and column of the extended matrix). 33 | To compute this commitment, the block producer performs the following operations: 34 | 35 | - It splits the executable transactions and the namespaced data 36 | into shares. Every share consists of some bytes prefixed by a 37 | namespace. To this end, the executable transactions are associated 38 | with a reserved namespace. 39 | - It arranges these shares into a square matrix (row-wise). Note that 40 | the shares are padded to the next power of two. The outcome square 41 | of size $k \times k$ is referred to as the original data. 42 | - It extends the original data to a $2k \times 2k$ square matrix using 43 | the 2-dimensional Reed-Solomon encoding scheme described above. 44 | The extended shares (i.e., containing erasure data) are associated 45 | with another reserved namespace. 46 | - It computes a commitment for every row and column of the extended 47 | matrix using the NMTs described above. 48 | 49 | Thus, the commitment of the block data is the root of a Merkle tree 50 | with the leaves the roots of a forest of Namespaced Merkle subtrees, 51 | one for every row and column of the extended matrix. 52 | 53 | ## Checking data availability 54 | 55 | ![DA network](/img/learn/consensus-da.png) 56 | 57 | To enhance connectivity, the celestia-node augments the celestia-app 58 | with a separate libp2p network, _i.e._, the so-called _DA network_, 59 | that serves DAS requests. 60 | 61 | Light nodes connect to a celestia-node in the DA network, listen to 62 | extended block headers (i.e., the block headers together with the 63 | relevant DA metadata, such as the $4k$ intermediate Merkle roots), and 64 | perform DAS on the received headers (i.e., ask for random data shares). 65 | 66 | Note that although it is recommended, performing DAS is optional -- light 67 | nodes could just trust that the data corresponding to the commitments in 68 | the block headers was indeed made available by the Celestia DA layer. 69 | In addition, light nodes can also submit transactions to the celestia-app, 70 | i.e., `PayForBlobs` transactions. 71 | 72 | While performing DAS for a block header, every light node queries Celestia 73 | Nodes for a number of random data shares from the extended matrix and the 74 | corresponding Merkle proofs. If all the queries are successful, then the 75 | light node accepts the block header as valid (from a DA perspective). 76 | 77 | If at least one of the queries fails (i.e., either the data share is not 78 | received or the Merkle proof is invalid), then the light node rejects the 79 | block header and tries again later. The retrial is necessary to deal with 80 | false negatives, i.e., block headers being rejected although the block 81 | data is available. This may happen due to network congestion for example. 82 | 83 | Alternatively, light nodes may accept a block header although the data 84 | is not available, i.e., a _false positive_. This is possible since the 85 | soundness property (i.e., if an honest light node accepts a block as available, 86 | then at least one honest full node will eventually have the entire block data) 87 | is probabilistically guaranteed (for more details, take a look at the 88 | [original paper](https://arxiv.org/abs/1809.09044)). 89 | 90 | By fine tuning Celestia's parameters (e.g., the number of data shares sampled 91 | by each light node) the likelihood of false positives can be sufficiently 92 | reduced such that block producers have no incentive to withhold the block data. 93 | -------------------------------------------------------------------------------- /learn/how-to-stake-tia.md: -------------------------------------------------------------------------------- 1 | --- 2 | sidebar_label: How to stake TIA 3 | description: This tutorial covers how to stake TIA with Keplr, Leap, or Gem wallet 4 | --- 5 | 6 | # How to stake TIA 7 | 8 | Celestia is a proof-of-stake blockchain based on the Cosmos SDK. 9 | 10 | Staking TIA as a delegator allows you to secure the Celestia network. 11 | This means that you can stake the native token TIA and vote on governance 12 | proposals. 13 | 14 | In this tutorial, you will learn how to stake TIA tokens via 15 | [Keplr](https://www.keplr.app/), [Leap](https://www.leapwallet.io/), and [Gem](https://gemwallet.com/) 16 | wallets. 17 | 18 | ## Select your preferred wallet 19 | 20 | 21 |
22 | 23 | Keplr 24 | 25 |
26 | 27 |
28 | 29 | Leap 30 | 31 |
32 | 33 |
34 | 35 | Gem Wallet 36 | 37 |
38 | 39 | ## Stake TIA with Keplr wallet 40 | 41 | ### :one: Open your Keplr browser extension 42 | 43 | Navigate to `Staked` and select `Stake with Keplr Dashboard`. 44 | 45 | This will open the Keplr dashboard in a new browser page. 46 | 47 | ![Keplr1](/img/keplr/keplr1.gif) 48 | 49 | ### :two: Select Celestia network and search for a validator 50 | 51 | In the Keplr dashboard, select the `Celestia` network and pick a 52 | validator of your choice. 53 | 54 | ![Keplr1](/img/keplr/keplr2.gif) 55 | 56 | ### :three: Stake your TIA tokens 57 | 58 | On the following screen enter the amount of TIA tokens and select `Stake`. 59 | 60 | A Keplr popup will appear, requesting your approval for the 61 | transaction. Select `Approve`. 62 | 63 | ![Keplr1](/img/keplr/keplr3.gif) 64 | 65 | ### :four: Confirm and manage your TIA 66 | 67 | After the transaction is confirmed, you will see the following 68 | overview dashboard where you can claim rewards, unstake, redelegate, 69 | or stake additional tokens. 70 | 71 | ![Keplr1](/img/keplr/keplr4.gif) 72 | 73 | ## Stake TIA with Leap wallet 74 | 75 | ### :one: Open your Leap browser extension 76 | 77 | In the top right select `Celestia` network and navigate to `Stake`. 78 | 79 | Similarly to the previous step, select the `+Stake` button. 80 | 81 | ![Keplr1](/img/leap/leap1.gif) 82 | 83 | ### :two: Select a validator and stake TIA 84 | 85 | On the following screen choose a validator of your choice, enter 86 | the desired amount, and click `Review`. 87 | 88 | Following that, review the transaction details and select `Stake`, 89 | then wait for the transaction to be finalized. 90 | 91 | ![Keplr1](/img/leap/leap2.gif) 92 | 93 | ### :three: Confirm and manage your TIA 94 | 95 | After the transaction is confirmed, you will see the following 96 | overview dashboard where you can claim rewards, unstake, redelegate, 97 | or stake additional tokens. 98 | 99 | ![Keplr1](/img/leap/leap3.gif) 100 | 101 | ## Stake TIA with Gem wallet 102 | 103 | ### :one: Open your Gem Wallet app 104 | 105 | Navigate to `Celestia` and select `Stake`. 106 | 107 | ![Gem1](/img/gem/gem1.gif) 108 | 109 | ### :two: Choose the amount of Celestia tokens and search for a validator 110 | 111 | Select the amount of Celestia tokens and choose a validator from the list. 112 | 113 | ![Gem2](/img/gem/gem2.gif) 114 | 115 | ### :three: Stake your TIA tokens 116 | 117 | Review the network terms and commission, then press `Confirm` to proceed. 118 | 119 | ![Gem3](/img/gem/gem3.gif) 120 | 121 | ### :four: Manage your TIA 122 | 123 | After your transaction is confirmed, you will have access to a control panel where you can claim rewards, unstake, redelegate, or stake additional tokens. 124 | 125 | ![Gem4](/img/gem/gem4.gif) 126 | -------------------------------------------------------------------------------- /learn/paying-for-blobspace.md: -------------------------------------------------------------------------------- 1 | # Paying for blobspace 2 | 3 | ## PayForBlobs transactions 4 | 5 | To publish data on Celestia, developers can submit `PayForBlobs` transactions. A 6 | `PayForBlobs` transaction consists of the identity of the sender, the data to be 7 | made available, the data size, the namespace, and a signature. 8 | 9 | Each `PayForBlobs` transaction is split into two parts: the blob or blobs which 10 | include the data to be made available along with the namespace, and the executable 11 | payment transaction which includes a commitment to the data. 12 | 13 | Both the blobs and executable payment transactions are put into the block within 14 | the appropriate namespace. The block data is extended using erasure coding and then 15 | Merkelized into a data root commitment included in the block header. 16 | 17 | ![Lifecycle of a celestia-app Transaction](/img/learn/tx-lifecycle.png) 18 | 19 | See 20 | [the detailed life cycle of a Celestia transaction](/learn/how-celestia-works/transaction-lifecycle.md). 21 | 22 | Learn how to 23 | [submit data to Celestia’s data availability layer](/how-to-guides/submit-data.md). 24 | 25 | ## Fee market overview 26 | 27 | Celestia uses a standard gas-price prioritised mempool. This means that 28 | transactions with higher fees will be prioritised by validators. Fees are 29 | comprised of a flat fee per transaction and then a variable fee based on the 30 | size of each blob in the transaction. 31 | 32 | Understand how fees are calculated on Celestia in 33 | [the overview on submitting PFB transactions](/how-to-guides/submit-data.md). 34 | -------------------------------------------------------------------------------- /learn/retrievability.md: -------------------------------------------------------------------------------- 1 | --- 2 | sidebar_label: Data retrievability and pruning 3 | description: Practices and expectations for data retrievability and pruning on Celestia. 4 | --- 5 | 6 | # Data retrievability and pruning 7 | 8 | The purpose of data availability layers such as Celestia is to ensure 9 | that block data is provably published, so that applications 10 | and rollups can know what the state of their chain is, and store that data. 11 | Once the data is published, data availability layers 12 | [do not inherently guarantee that historical data will be permanently stored](https://notes.ethereum.org/@vbuterin/proto_danksharding_faq#If-data-is-deleted-after-30-days-how-would-users-access-older-blobs) 13 | and remain retrievable. 14 | 15 | In this document, we discuss the state of data retrievability and 16 | pruning in Celestia, as well as some tips for rollup developers in 17 | order to ensure that syncing new rollup nodes is possible. 18 | 19 | ## Data retrievability and pruning in celestia-node 20 | 21 | As of version v0.13.0, celestia-node has implemented a light node 22 | sampling window of 30 days, as specified in 23 | [CIP-4](https://github.com/celestiaorg/CIPs/blob/main/cips/cip-004.md). 24 | This means that once pruning is implemented, 25 | light nodes will now only sample blocks within a 30-day 26 | window instead of sampling all blocks from genesis. This change 27 | introduces the concept of pruning to celestia-node, where data 28 | outside of the 30-day window may not be stored by light nodes, 29 | marking a significant update in how data retrievability and 30 | storage are managed within the network 31 | ([v0.13.0 release notes](https://github.com/celestiaorg/celestia-node/releases/tag/v0.13.0)). 32 | 33 | Data blobs older than the recency window will be pruned by default 34 | on light nodes, after pruning is fully implemented, 35 | but will continue to be stored by archival nodes that do not prune data. Light 36 | nodes will be able to query historic blob data in namespaces from archival 37 | nodes, as long as archival nodes exist on the public network. 38 | 39 | Once pruning is fully implemented, light nodes will only perform data 40 | availability sampling for blocks within the data recency window of 30 days. 41 | 42 | ## Suggested practices for rollups 43 | 44 | Rollups may need to access historic data in order to allow new rollup nodes 45 | to reconstruct the latest state by replaying historical blocks. Once data has 46 | been published on Celestia and guaranteed to have been made available, rollups 47 | and applications are responsible for storing their historical data. 48 | 49 | While it is possible to continue to do this by using the `GetAll` API method in 50 | celestia-node on historic blocks as long as archival nodes exist on the public 51 | Celestia network, rollup developers should not rely on this as the only method 52 | to access historical data, as archival nodes serving requests for historical 53 | data for free is not guaranteed. Below are some other suggested methods to 54 | access historical data. 55 | 56 | - **Use professional archival node or data providers.** It is expected that 57 | professional infrastructure providers will provide paid access to archival 58 | nodes, where historical data can be retrieved, for example using the `GetAll` 59 | API method. Providers like QuickNode offer archival node services that maintain 60 | complete historical data, ensuring reliable access to past transactions and state. 61 | This provides better guarantees than solely relying on free archival nodes on the 62 | public Celestia network. For a list of available providers, see the 63 | [network pages](/how-to-guides/mainnet.md) page, and for specific archival 64 | node endpoints, refer to the [archival DA RPC endpoints](/how-to-guides/mainnet.md#archival-da-rpc-endpoints) 65 | section. 66 | 67 | - **Share snapshots of rollup nodes.** Rollups could share snapshots of their 68 | data directories which can be downloaded manually by users bootstrapping new 69 | nodes. These snapshots could contain the latest state of the rollup, and/or 70 | all the historical blocks. 71 | - **Add peer-to-peer support for historical block sync.** A less manual version 72 | of sharing snapshots, where rollup nodes could implement built-in support for 73 | block sync, where rollup nodes download historical block data from each other 74 | over a peer-to-peer network. 75 | - [**Namespace pinning.**](https://github.com/celestiaorg/celestia-node/issues/2830) 76 | In the future, celestia-node is expected to allow nodes to choose to "pin" 77 | data from selected namespaces that they wish to store and make available for 78 | other nodes. This will allow rollup nodes to be responsible for storing their 79 | data, without needing to implement their own peer-to-peer historical block 80 | sync mechanism. 81 | -------------------------------------------------------------------------------- /learn/staking.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: Learn how to stake your tokens on the Celestia network. 3 | --- 4 | 5 | # Staking on Celestia 6 | 7 | Engage with the Celestia network at a deeper level through staking. An 8 | essential mechanism to a proof-of-stake network, users can secure the 9 | network by delegating to a validator and receive a share of its 10 | staking rewards. 11 | 12 | ## Mainnet Beta 13 | 14 | Currently, the following staking interfaces exist for the 15 | [Mainnet Beta](/how-to-guides/mainnet.md). 16 | 17 | Just connect your wallet to get started! 18 | 19 | - [https://wallet.keplr.app/chains/celestia?tab=staking](https://wallet.keplr.app/chains/celestia?tab=staking) 20 | - [https://app.leapwallet.io/transact/stake/plain?chain=celestia](https://app.leapwallet.io/transact/stake/plain?chain=celestia) 21 | - [https://alphab.ai/s/m/celestia/](https://alphab.ai/s/m/celestia/) 22 | 23 | ## Mocha testnet 24 | 25 | Currently, the following staking interfaces exist for the 26 | [Mocha testnet](/how-to-guides/mocha-testnet.md). 27 | 28 | Just connect your wallet to get started! 29 | 30 | - [https://testnet.keplr.app/chains/celestia-mocha-testnet](https://testnet.keplr.app/chains/celestia-mocha-testnet) 31 | - [https://explorer.kjnodes.com/celestia-testnet](https://explorer.kjnodes.com/celestia-testnet) 32 | - [https://alphab.ai/s/t/celestia-mocha-4/](https://alphab.ai/s/t/celestia-mocha-4/) 33 | -------------------------------------------------------------------------------- /learn/tia.md: -------------------------------------------------------------------------------- 1 | --- 2 | prev: 3 | text: "Data availability FAQ" 4 | link: "/learn/how-celestia-works/data-availability-faq" 5 | --- 6 | 7 | # Overview of TIA 8 | 9 | ## TIA at a glance 10 | 11 | 12 | 13 | | Property | Details | 14 | | ----------------------- | ------------------------------------------------------------------------------------------------ | 15 | | Abbreviation | TIA | 16 | | Total supply at genesis | 1,000,000,000 TIA | 17 | | Inflation schedule | 8% in the first year, decreasing 10% per year until reaching an inflation floor of 1.5% annually | 18 | | Decimals | 6 | 19 | | Conversion | $\text{1 uTIA} = \text{TIA} \times 10^{-6}$ | 20 | 21 | 22 | 23 | ## Role of TIA 24 | 25 | ### Paying for blobspace 26 | 27 | Celestia’s native asset, TIA, is an essential part of how developers build on 28 | the first modular blockchain network. To use Celestia for data availability, 29 | rollup developers submit PayForBlobs transactions on the network for a fee, 30 | denominated in TIA. 31 | 32 | ### Bootstrapping new rollups 33 | 34 | A core part of the Celestia vision is that deploying a blockchain should be as 35 | easy as deploying a smart contract. In the modular era, developers no longer 36 | need to issue a token to launch their own blockchain. 37 | 38 | Similarly to ETH on Ethereum-based rollups, developers may opt to bootstrap 39 | their chain quickly by using TIA as a gas token and currency, in addition to 40 | paying for data availability. In this mode, developers can focus on creating 41 | their application or execution layer, instead of issuing a token right away. 42 | 43 | ### Proof-of-stake 44 | 45 | As a permissionless network built with Cosmos SDK, Celestia uses proof-of-stake 46 | to secure its own consensus. Like in other Cosmos networks, any user can help 47 | secure the network by delegating their TIA to a Celestia validator for a portion 48 | of their validator’s staking rewards. 49 | 50 | Learn [how proof-of-stake works in Cosmos](https://docs.cosmos.network/main/modules/staking). 51 | 52 | ### Decentralised governance 53 | 54 | TIA staking also allows the community to play a critical role in decentralised 55 | governance over key parts of Celestia, such as voting on network parameters 56 | through governance proposals, and governing the community pool, which receives 57 | 2% of block rewards. 58 | 59 | Learn more about [Celestia’s decentralised governance model](/how-to-guides/staking-governance-supply.md#decentralised-governance). 60 | 61 | ### Denominations 62 | 63 | #### TIA: display token 64 | 65 | TIA is the [`DisplayDenom`](https://github.com/celestiaorg/celestia-app/blob/ada77509d7fdedf2a3e3400b720549365851454c/app/app.go#L110-L111) 66 | that you will typically see in wallets and user interfaces. 67 | 68 | #### utia: staking denomination 69 | 70 | `utia` is the [`BondDenom`](https://github.com/celestiaorg/celestia-app/blob/ada77509d7fdedf2a3e3400b720549365851454c/pkg/appconsts/global_consts.go#L75-L76) 71 | and stands for "micro TIA", with 1 TIA = 1,000,000 `utia`. This is the 72 | native staking denomination. 73 | 74 | In staking operations or transactions, if no denomination is specified, `utia` 75 | is assumed. 76 | 77 | #### microtia: staking denomination alias 78 | 79 | `microtia` is the [`BondDenomAlias`](https://github.com/celestiaorg/celestia-app/blob/ada77509d7fdedf2a3e3400b720549365851454c/app/app.go#L108-L109), 80 | an alias for `utia`. 81 | -------------------------------------------------------------------------------- /lychee.toml: -------------------------------------------------------------------------------- 1 | # Configuration for lychee link checker 2 | # See: https://lychee.cli.rs/ 3 | 4 | cache = true 5 | exclude_all_private = true 6 | exclude_path = ["./node_modules"] 7 | max_cache_age = "10d" 8 | max_redirects = 10 9 | max_retries = 3 10 | 11 | exclude = [ 12 | # rate limited / 403 / 503 / whatever 13 | "https://explorer.celestia-arabica-11.com/", 14 | "https://arabica.celenium.io/", 15 | "https://sepolia.arbiscan.io/", 16 | "https://arbiscan.io/", 17 | "https://basescan.org/", 18 | "https://sepolia.basescan.org/", 19 | "https://etherscan.io/*", 20 | "https://sepolia.etherscan.io/*", 21 | "https://scrollscan.com/*", 22 | "https://celenium.io/", 23 | "https://mocha.celenium.io", 24 | "https://mocha-4.celenium.io/", 25 | "https://celestia-testnet-api.itrocket.net/", 26 | "https://platform.openai.com/", 27 | "https://analytics.smartstake.io/", 28 | # Additional exclusions from failing checks 29 | "https://x.com/*", 30 | "https://twitter.com/*", 31 | "https://explorer.celestia*", 32 | "mamochain.com", 33 | "https://polkachu.com/tendermint_snapshots/*", 34 | "https://polkachu.com/archive_snapshots/*", 35 | "https://polkachu.com/testnets/*", 36 | # Social media platforms 37 | "https://discord.gg/*", 38 | "https://discord.com/*", 39 | # Additional exclusions per CI feedback request 40 | "https://vitepress.dev", 41 | "https://validao.xyz/*", 42 | "https://faucet.celestia*", 43 | "https://dl.acm.org/doi/abs/10.1145/98163.98167", 44 | # skip any templates used in URLs for `.vitepress/components/*.vue` 45 | # matches "{.*}" literals in URLs 46 | '\%7B.*\%7D', 47 | ] 48 | -------------------------------------------------------------------------------- /package.json: -------------------------------------------------------------------------------- 1 | { 2 | "scripts": { 3 | "dev": "vitepress dev", 4 | "build": "vitepress build", 5 | "preview": "vitepress preview", 6 | "prepare": "husky install", 7 | "lint": "eslint --fix", 8 | "lint:md": "markdownlint '**/*.md'", 9 | "format": "prettier --write '**/*.{js,jsx,ts,tsx,md,json,css,scss}'", 10 | "link-check": "lychee --config lychee.toml '**/*.md' '.vitepress/config.ts'" 11 | }, 12 | "devDependencies": { 13 | "@commitlint/cli": "^17.7.2", 14 | "@commitlint/config-conventional": "^17.7.0", 15 | "@typescript-eslint/eslint-plugin": "^6.7.5", 16 | "@typescript-eslint/parser": "^6.7.5", 17 | "eslint": "^8.51.0", 18 | "eslint-plugin-vue": "^9.17.0", 19 | "husky": "^8.0.3", 20 | "i": "^0.3.7", 21 | "lint-staged": "^14.0.1", 22 | "markdownlint-cli": "^0.37.0", 23 | "prettier": "^3.0.3", 24 | "typescript": "^5.2.2", 25 | "vitepress": "1.0.0-rc.24" 26 | }, 27 | "dependencies": { 28 | "@fortawesome/fontawesome-free": "^6.4.2", 29 | "markdown-it-mathjax3": "^4.3.2", 30 | "v-tooltip": "^2.1.3", 31 | "vue-clipboard2": "^0.3.3" 32 | }, 33 | "lint-staged": { 34 | "*.{js,jsx,ts,tsx}": [ 35 | "yarn lint", 36 | "yarn format" 37 | ], 38 | "*.md": [ 39 | "yarn lint:md" 40 | ] 41 | } 42 | } 43 | -------------------------------------------------------------------------------- /public/Blobspace.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/Blobspace.png -------------------------------------------------------------------------------- /public/Celestia-og.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/Celestia-og.png -------------------------------------------------------------------------------- /public/Documentation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/Documentation.png -------------------------------------------------------------------------------- /public/audits/Blobstream_X-Informal_Systems_Audit.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/audits/Blobstream_X-Informal_Systems_Audit.pdf -------------------------------------------------------------------------------- /public/audits/Blobstream_X-OtterSec_Audit.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/audits/Blobstream_X-OtterSec_Audit.pdf -------------------------------------------------------------------------------- /public/audits/Blobstream_X-Veridise_Audit.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/audits/Blobstream_X-Veridise_Audit.pdf -------------------------------------------------------------------------------- /public/audits/Blobstream_X-Zellic_Audit.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/audits/Blobstream_X-Zellic_Audit.pdf -------------------------------------------------------------------------------- /public/audits/Celestia_OP_Stack_Audit.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/audits/Celestia_OP_Stack_Audit.pdf -------------------------------------------------------------------------------- /public/audits/SP1_Blobstream_Ottersec_Audit.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/audits/SP1_Blobstream_Ottersec_Audit.pdf -------------------------------------------------------------------------------- /public/audits/celestia_shwap_audit_final.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/audits/celestia_shwap_audit_final.pdf -------------------------------------------------------------------------------- /public/build/altlayer.webp: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/build/altlayer.webp -------------------------------------------------------------------------------- /public/build/arbitrum.webp: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/build/arbitrum.webp -------------------------------------------------------------------------------- /public/build/astria.webp: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/build/astria.webp -------------------------------------------------------------------------------- /public/build/caldera.webp: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/build/caldera.webp -------------------------------------------------------------------------------- /public/build/conduit.webp: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/build/conduit.webp -------------------------------------------------------------------------------- /public/build/dymension.webp: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/build/dymension.webp -------------------------------------------------------------------------------- /public/build/gateway.webp: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/build/gateway.webp -------------------------------------------------------------------------------- /public/build/gelato.webp: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/build/gelato.webp -------------------------------------------------------------------------------- /public/build/karnot.webp: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/build/karnot.webp -------------------------------------------------------------------------------- /public/build/lumoz.webp: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/build/lumoz.webp -------------------------------------------------------------------------------- /public/build/opstack.webp: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/build/opstack.webp -------------------------------------------------------------------------------- /public/build/polygon.webp: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/build/polygon.webp -------------------------------------------------------------------------------- /public/build/rollkit.webp: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/build/rollkit.webp -------------------------------------------------------------------------------- /public/build/snapchain.webp: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/build/snapchain.webp -------------------------------------------------------------------------------- /public/build/sovereign.webp: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/build/sovereign.webp -------------------------------------------------------------------------------- /public/build/stackr.webp: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/build/stackr.webp -------------------------------------------------------------------------------- /public/build/vistara.webp: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/build/vistara.webp -------------------------------------------------------------------------------- /public/build/zeeve.webp: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/build/zeeve.webp -------------------------------------------------------------------------------- /public/favicons/favicon-dark.ico: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/favicons/favicon-dark.ico -------------------------------------------------------------------------------- /public/favicons/favicon-dark.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/favicons/favicon-dark.png -------------------------------------------------------------------------------- /public/favicons/favicon-dark.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 9 | 10 | 11 | -------------------------------------------------------------------------------- /public/favicons/favicon.ico: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/favicons/favicon.ico -------------------------------------------------------------------------------- /public/favicons/favicon.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/favicons/favicon.png -------------------------------------------------------------------------------- /public/favicons/favicon.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 9 | 10 | 11 | -------------------------------------------------------------------------------- /public/fonts/untitled-sans/untitled-sans-medium.woff2: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/fonts/untitled-sans/untitled-sans-medium.woff2 -------------------------------------------------------------------------------- /public/fonts/untitled-sans/untitled-sans-regular.woff2: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/fonts/untitled-sans/untitled-sans-regular.woff2 -------------------------------------------------------------------------------- /public/fonts/youth/Youth-Regular.woff: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | -------------------------------------------------------------------------------- /public/fonts/youth/Youth-Regular.woff2: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/fonts/youth/Youth-Regular.woff2 -------------------------------------------------------------------------------- /public/grove/grove-sandbox.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/grove/grove-sandbox.png -------------------------------------------------------------------------------- /public/img/Celestia-Arbitrum.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/Celestia-Arbitrum.png -------------------------------------------------------------------------------- /public/img/Celestia_Bubs_Testnet.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/Celestia_Bubs_Testnet.jpg -------------------------------------------------------------------------------- /public/img/Celestia_Modular_meetup2.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/Celestia_Modular_meetup2.jpg -------------------------------------------------------------------------------- /public/img/Celestia_ethereum-fallback.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/Celestia_ethereum-fallback.jpg -------------------------------------------------------------------------------- /public/img/Mainnet-Beta.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/Mainnet-Beta.png -------------------------------------------------------------------------------- /public/img/arabica-devnet.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/arabica-devnet.png -------------------------------------------------------------------------------- /public/img/blobstream/Blobstream.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/blobstream/Blobstream.png -------------------------------------------------------------------------------- /public/img/blobstream/Celestia_Blobstream_X1b.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/blobstream/Celestia_Blobstream_X1b.png -------------------------------------------------------------------------------- /public/img/blobstream/Celestia_Blobstream_X2b.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/blobstream/Celestia_Blobstream_X2b.png -------------------------------------------------------------------------------- /public/img/blobstream/Celestia_Blobstream_attestation_flow.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/blobstream/Celestia_Blobstream_attestation_flow.jpg -------------------------------------------------------------------------------- /public/img/blobstream/blobstream-commitment-diagram.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/blobstream/blobstream-commitment-diagram.png -------------------------------------------------------------------------------- /public/img/blobstream/blobstream-orchestrator.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/blobstream/blobstream-orchestrator.png -------------------------------------------------------------------------------- /public/img/blobstream/blobstream-relayer.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/blobstream/blobstream-relayer.png -------------------------------------------------------------------------------- /public/img/blobstream/blobstream-square.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/blobstream/blobstream-square.png -------------------------------------------------------------------------------- /public/img/blobstream/blobstream_logo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/blobstream/blobstream_logo.png -------------------------------------------------------------------------------- /public/img/celestia_mammoths_transparent_bg.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/celestia_mammoths_transparent_bg.png -------------------------------------------------------------------------------- /public/img/cohort-timeline.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/cohort-timeline.jpg -------------------------------------------------------------------------------- /public/img/da-and-validity.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/da-and-validity.png -------------------------------------------------------------------------------- /public/img/ecosystem-delegation-program.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/ecosystem-delegation-program.jpg -------------------------------------------------------------------------------- /public/img/foundation-delegation-program.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/foundation-delegation-program.jpg -------------------------------------------------------------------------------- /public/img/gem.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/gem.png -------------------------------------------------------------------------------- /public/img/gem/gem1.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/gem/gem1.gif -------------------------------------------------------------------------------- /public/img/gem/gem2.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/gem/gem2.gif -------------------------------------------------------------------------------- /public/img/gem/gem3.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/gem/gem3.gif -------------------------------------------------------------------------------- /public/img/gem/gem4.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/gem/gem4.gif -------------------------------------------------------------------------------- /public/img/gm-arb.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/gm-arb.png -------------------------------------------------------------------------------- /public/img/gm_bubs.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/gm_bubs.png -------------------------------------------------------------------------------- /public/img/gm_contract.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/gm_contract.png -------------------------------------------------------------------------------- /public/img/keplr.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/keplr.png -------------------------------------------------------------------------------- /public/img/keplr/keplr1.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/keplr/keplr1.gif -------------------------------------------------------------------------------- /public/img/keplr/keplr2.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/keplr/keplr2.gif -------------------------------------------------------------------------------- /public/img/keplr/keplr3.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/keplr/keplr3.gif -------------------------------------------------------------------------------- /public/img/keplr/keplr4.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/keplr/keplr4.gif -------------------------------------------------------------------------------- /public/img/leap.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/leap.png -------------------------------------------------------------------------------- /public/img/leap/leap1.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/leap/leap1.gif -------------------------------------------------------------------------------- /public/img/leap/leap2.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/leap/leap2.gif -------------------------------------------------------------------------------- /public/img/leap/leap3.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/leap/leap3.gif -------------------------------------------------------------------------------- /public/img/learn/Celestia_TIA_Allocation_at_Genesis.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/learn/Celestia_TIA_Allocation_at_Genesis.png -------------------------------------------------------------------------------- /public/img/learn/Celestia_TIA_Available_Supply.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/learn/Celestia_TIA_Available_Supply.png -------------------------------------------------------------------------------- /public/img/learn/Celestia_TIA_Inflation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/learn/Celestia_TIA_Inflation.png -------------------------------------------------------------------------------- /public/img/learn/celestia-app.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/learn/celestia-app.png -------------------------------------------------------------------------------- /public/img/learn/consensus-da.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/learn/consensus-da.png -------------------------------------------------------------------------------- /public/img/learn/data-availability-faq/Data-availability.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/learn/data-availability-faq/Data-availability.png -------------------------------------------------------------------------------- /public/img/learn/data-availability-faq/Data-storage.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/learn/data-availability-faq/Data-storage.png -------------------------------------------------------------------------------- /public/img/learn/monolithic-modular.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/learn/monolithic-modular.png -------------------------------------------------------------------------------- /public/img/learn/nmt.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/learn/nmt.png -------------------------------------------------------------------------------- /public/img/learn/reed-solomon-encoding.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/learn/reed-solomon-encoding.png -------------------------------------------------------------------------------- /public/img/learn/tx-lifecycle.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/learn/tx-lifecycle.png -------------------------------------------------------------------------------- /public/img/mamo-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/mamo-1.png -------------------------------------------------------------------------------- /public/img/mamo/mamo-blob.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/mamo/mamo-blob.png -------------------------------------------------------------------------------- /public/img/mamo/mamo-dbenter.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/mamo/mamo-dbenter.png -------------------------------------------------------------------------------- /public/img/mamo/mamo-dbstart.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/mamo/mamo-dbstart.png -------------------------------------------------------------------------------- /public/img/mamo/mamo-nodeinfo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/mamo/mamo-nodeinfo.png -------------------------------------------------------------------------------- /public/img/mamo/mamo-post.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/mamo/mamo-post.png -------------------------------------------------------------------------------- /public/img/mamo/mamo-retrieve.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/mamo/mamo-retrieve.png -------------------------------------------------------------------------------- /public/img/mamo/mamo-sampler.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/mamo/mamo-sampler.png -------------------------------------------------------------------------------- /public/img/mocha.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/mocha.jpg -------------------------------------------------------------------------------- /public/img/modular_fellows.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/modular_fellows.jpg -------------------------------------------------------------------------------- /public/img/nitrogen-testnet.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/nitrogen-testnet.jpg -------------------------------------------------------------------------------- /public/img/nodes/BridgeNodes.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/nodes/BridgeNodes.png -------------------------------------------------------------------------------- /public/img/nodes/LightNodes.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/nodes/LightNodes.png -------------------------------------------------------------------------------- /public/img/nodes/consensus-node.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/nodes/consensus-node.jpg -------------------------------------------------------------------------------- /public/img/nodes/full-storage-node.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/nodes/full-storage-node.png -------------------------------------------------------------------------------- /public/img/nodes/validator.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/nodes/validator.png -------------------------------------------------------------------------------- /public/img/rollkit.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/celestiaorg/docs/944034020c638b30c9b7fc3c95186d39b1824173/public/img/rollkit.png -------------------------------------------------------------------------------- /tutorials/integrate-celestia.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: Learn how service providers can integrate with the Celestia network. 3 | prev: 4 | text: "Integrating Wallets for developers" 5 | link: "/tutorials/wallets" 6 | --- 7 | 8 | # Integrate Celestia for service providers 9 | 10 | This document is for third-party service providers, such as custodians and 11 | explorers, integrating the Celestia network. 12 | 13 | ## Getting started 14 | 15 | When getting started with Celestia, we recommend checking out these resources first: 16 | 17 | - [Introduction to Celestia](/learn/how-celestia-works/overview.md) 18 | - [Monolithic v. Modular](/learn/how-celestia-works/monolithic-vs-modular.md) 19 | - [Celestia's DA Layer](/learn/how-celestia-works/data-availability-layer.md) 20 | - [Overview to running nodes on Celestia](/how-to-guides/nodes-overview.md) 21 | - [Rollup stacks](/how-to-guides/rollup-stacks.md) 22 | 23 | ## Celestia service provider notes 24 | 25 | Celestia is a fairly standard Cosmos-SDK based chain. We use the latest version 26 | of Tendermint and the Cosmos-SDK, with only minor modifications to each. This 27 | means that we are: 28 | 29 | - Using the default Cosmos-SDK modules: auth, bank, distribution, staking, 30 | slashing, mint, crisis, ibchost, genutil, evidence, ibctransfer, params, gov 31 | (limited in some TBD capacities), upgrade, vesting, feegrant, capability, and 32 | payment. 33 | - Use the standard digital keys schemes provided by the Cosmos-SDK and 34 | Tendermint, those being secp256k1 for user transactions, and tm-ed25519 for 35 | signing and verifying consensus messages. 36 | 37 | While exactly which modules used is subject to change, Celestia aims to be as 38 | minimal as possible. 39 | 40 | ### Custody and key management 41 | 42 | Celestia supports many already existing key management systems, as we rely on 43 | the Cosmos-SDK and Tendermint libraries for signing and verifying transactions. 44 | Learn more in the 45 | [Cosmos-SDK documentation](https://docs.cosmos.network/main/learn/beginner/accounts#keys-accounts-addresses-and-signatures) 46 | 47 | ### RPC and querying 48 | 49 | In celestia-app, only the standard RPC endpoints for Tendermint and the 50 | Cosmos-SDK are exposed. We do not currently add or subtract any core 51 | functionality, but this could change in the future. The same goes for querying 52 | data from the chain. 53 | 54 | In celestia-node, the Data Availability node client, there is a JSON-RPC API 55 | that allows you to interact directly with Celestia's Data Availability layer. 56 | Learn [how to use the API in this tutorial](/tutorials/node-tutorial.md). 57 | 58 | ### Compatibility 59 | 60 | Linux, particularly Ubuntu 20.04 LTS, is the most well tested. Potentially 61 | compatible with other OSs, but they are currently untested. Some of the 62 | cryptography libraries used for erasure data are not guaranteed to work on 63 | other platforms. 64 | 65 | ### Syncing 66 | 67 | Since we utilize Tendermint and the Cosmos-SDK, syncing the chain can be 68 | performed by any method that is supported by those libraries. This includes 69 | fast-sync, state sync, and quick sync. 70 | 71 | ### Notable exceptions relative to other blockchains 72 | 73 | Relative to other Tendermint based chains, Celestia will have significantly 74 | longer blocktimes of roughly 6\* seconds. The reason behind this block time is to 75 | optimize the bandwidth used by light clients that are sampling the chain, and 76 | is not because we have modified Tendermint consensus in any meaningful way. 77 | Validators will likely download/upload relatively large blocks. It should be 78 | noted that while these blocks are large, very little typical blockchain state 79 | execution is actually occurring on Celestia. Meaning that the bandwidth 80 | requirements will likely be larger than that of a typical Cosmos-SDK based 81 | blockchain full node, the computing requirements should be similar in 82 | magnitude. 83 | 84 | \*Subject to Change 85 | -------------------------------------------------------------------------------- /tutorials/node-api.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: An overview of the celestia-node API. 3 | prev: 4 | text: "New Blobstream X deployments" 5 | link: "/how-to-guides/blobstream-x-deploy.md" 6 | --- 7 | 8 | # Node API 9 | 10 | The celestia-node API is made for interacting with celestia-node. 11 | There are two ways in which a user and developer can interact with 12 | the API, the RPC API and the Gateway API. View 13 | [the API's documentation](https://node-rpc-docs.celestia.org/). 14 | 15 | ## RPC API 16 | 17 | The RPC API primarily focuses on developers and projects building on 18 | top of Celestia, who are willing to run their own DA nodes. The RPC API 19 | provides a richer set of features and a superior user experience. 20 | Unlike the Gateway API, the RPC API allows access 21 | to the internal wallet and keyring of the DA node, as well as other 22 | sensitive and administrative capabilities. 23 | 24 | ### Library 25 | 26 | The node can be used as a Golang library and designed for programmatic API access. 27 | 28 | 30 | 31 | ### RPC 32 | 33 | The RPC API is also exposed to OpenRPC(JSON-RPC 2.0) for users wanting 34 | to run their DA node as a separate DA service. It provides the same 35 | set of features as the library with an additional authentication system 36 | with different permissions levels to protect the wallet and 37 | signing + providing RPC-level DOS protection. 38 | 39 | ### RPC API tutorial 40 | 41 | The [quick start guide](/how-to-guides/quick-start.md) is the easiest way to get started. 42 | 43 | The [node tutorial](/tutorials/node-tutorial.md), which uses the RPC CLI, is the 44 | recommended way 45 | to learn more about interacting with your Celestia node. 46 | 47 | Other ways to get started are with the [Rust](/tutorials/rust-client-tutorial.md) and [Golang](/tutorials/golang-client-tutorial.md) tutorials. 48 | 49 | ## Gateway API 50 | 51 | :::warning 52 | The gateway endpoints have been deprecated and will be removed in the future. 53 | If you would like to use them anyway, you can 54 | [find more details on GitHub](https://github.com/celestiaorg/celestia-node/pull/2360). 55 | ::: 56 | 57 | The gateway API is a REST API which is meant to be deployed by infra 58 | providers to enable the public read-only gateway to the DA network for 59 | external users who don't want or can't run light nodes 60 | (like browsers currently) over HTTP. It has no wallet or signing 61 | functionality. 62 | 63 | 64 | -------------------------------------------------------------------------------- /tutorials/rust-client-tutorial.md: -------------------------------------------------------------------------------- 1 | --- 2 | next: 3 | text: "Create a wallet with celestia-node" 4 | link: "/tutorials/celestia-node-key" 5 | --- 6 | 7 | # Rust client library tutorial {#rust-client-library} 8 | 9 | This tutorial section will guide you through using the most common RPC endpoints with [Lumina](https://github.com/eigerco/lumina/tree/main/rpc)'s rust client library. 10 | 11 | Install [dependencies](/how-to-guides/environment.md) and 12 | [celestia-node](/how-to-guides/celestia-node.md) if you have 13 | not already. 14 | 15 | ## Project setup 16 | 17 | To start, add `celestia_rpc` and `celestia_types` as a dependency to your project: 18 | 19 | ```bash 20 | cargo add celestia_rpc celestia_types 21 | ``` 22 | 23 | To use the following methods, you will need the node URL and your auth token. To get your auth token, see this [guide](/tutorials/node-tutorial.md#auth-token). To run your node without an auth token, you can use the `--rpc.skip-auth` flag when starting your node. This allows you to pass an empty string as your auth token. 24 | 25 | The default URL is `http://localhost:26658`. If you would like to use subscription methods, such as `SubscribeHeaders` below, you must use the `ws` protocol in place of `http`: `ws://localhost:26658`. 26 | 27 | ## Submitting and retrieving blobs 28 | 29 | The [blob.Submit](https://node-rpc-docs.celestia.org/#blob.Submit) method takes an array of blobs and a gas price, returning the height the blob was successfully posted at. 30 | 31 | - The namespace can be generated with `Namespace::new_v0`. 32 | - The blobs can be generated with `Blob::new`. 33 | - You can set `GasPrice::default()` as the gas price to have celestia-node automatically determine an appropriate gas price. 34 | 35 | The [blob.GetAll](https://node-rpc-docs.celestia.org/#blob.GetAll) method takes a height and array of namespaces, returning the array of blobs found in the given namespaces. 36 | 37 | ```rust 38 | use celestia_rpc::{BlobClient, Client, HeaderClient, ShareClient}; 39 | use celestia_types::{nmt::Namespace, Blob, blob::SubmitOptions}; 40 | 41 | async fn submit_blob(url: &str, token: &str) { 42 | let client = Client::new(url, Some(token)) 43 | .await 44 | .expect("Failed creating rpc client"); 45 | 46 | // let's use the DEADBEEF namespace 47 | let namespace = Namespace::new_v0(&[0xDE, 0xAD, 0xBE, 0xEF]).expect("Invalid namespace"); 48 | 49 | // create a blob 50 | let blob = Blob::new(namespace, b"Hello, World!".to_vec()).expect("Blob creation failed"); 51 | 52 | // submit the blob to the network 53 | let height = client 54 | .blob_submit(&[blob.clone()], SubmitOptions::default()) 55 | .await 56 | .expect("Failed submitting blob"); 57 | 58 | println!("Blob was included at height {}", height); 59 | 60 | // fetch the blob back from the network 61 | let retrieved_blobs = client 62 | .blob_get_all(height, &[namespace]) 63 | .await 64 | .expect("Failed to retrieve blobs"); 65 | 66 | assert_eq!(retrieved_blobs.len(), 1); 67 | assert_eq!(retrieved_blobs[0].data, b"Hello, World!"); 68 | assert_eq!(retrieved_blobs[0].commitment, blob.commitment); 69 | } 70 | ``` 71 | 72 | ## Subscribing to new headers 73 | 74 | You can subscribe to new headers using the [header.Subscribe](https://node-rpc-docs.celestia.org/#header.Subscribe) method. This method returns a `Subscription` that will receive new headers as they are produced. In this example, we will fetch all blobs at the height of the new header in the `0xDEADBEEF` namespace. 75 | 76 | ```rust 77 | async fn subscribe_headers(url: &str, token: &str) { 78 | let client = Client::new(url, Some(token)) 79 | .await 80 | .expect("Failed creating rpc client"); 81 | 82 | let mut header_sub = client 83 | .header_subscribe() 84 | .await 85 | .expect("Failed subscribing to incoming headers"); 86 | 87 | // setup the namespace we will filter blobs by 88 | let namespace = Namespace::new_v0(&[0xDE, 0xAD, 0xBE, 0xEF]).expect("Invalid namespace"); 89 | 90 | while let Some(extended_header) = header_sub.next().await { 91 | match extended_header { 92 | Ok(header) => { 93 | let height = header.header.height.value(); 94 | // fetch all blobs at the height of the new header 95 | 96 | let blobs = match client.blob_get_all(height, &[namespace]).await { 97 | Ok(blobs) => blobs, 98 | Err(e) => { 99 | eprintln!("Error fetching blobs: {}", e); 100 | continue; 101 | } 102 | }; 103 | 104 | println!( 105 | "Found {} blobs at height {} in the 0xDEADBEEF namespace", 106 | blobs.len(), 107 | height 108 | ); 109 | } 110 | Err(e) => { 111 | eprintln!("Error receiving header: {}", e); 112 | } 113 | } 114 | } 115 | } 116 | 117 | ``` 118 | 119 | ## Fetching an Extended Data Square (EDS) 120 | 121 | You can fetch an [Extended Data Square (EDS)](https://celestiaorg.github.io/celestia-app/specs/data_structures.html#erasure-coding) using the [share.GetEDS](https://node-rpc-docs.celestia.org/#share.GetEDS) method. This method takes a header and returns the EDS at the given height. 122 | 123 | ```rust 124 | async fn get_eds(url: &str, token: &str) -> ExtendedDataSquare { 125 | let client = Client::new(url, Some(token)) 126 | .await 127 | .expect("Failed creating rpc client"); 128 | 129 | // first get the header of the block you want to fetch the EDS from 130 | let latest_header = client 131 | .header_local_head() 132 | .await 133 | .expect("Failed fetching header"); 134 | 135 | client 136 | .share_get_eds(&latest_header) 137 | .await 138 | .expect("Failed to get EDS from latest header") 139 | } 140 | ``` 141 | 142 | ## API documentation 143 | 144 | To see the full list of available methods, see the [API documentation](https://node-rpc-docs.celestia.org/). 145 | --------------------------------------------------------------------------------