Merge branch 'celestiaorg:main' into patch-1

.vitepress/config.ts

@@ -414,7 +414,7 @@ function sidebarHome() {
               text: "Consensus",
               collapsed: true,
               items: [
-                { text: "Full consensus node", link: "/nodes/full-consensus-node" },
+                { text: "Consensus node", link: "/nodes/consensus-node" },
                 { text: "Validator node", link: "/nodes/validator-node" },
               ],
             },
@@ -448,6 +448,10 @@ function sidebarHome() {
                   text: "Custom networks and values",
                   link: "/nodes/celestia-node-custom-networks",
                 },
+                {
+                  text: "Syncing a light node from a trusted hash",
+                  link: "/nodes/celestia-node-trusted-hash",
+                },
                 {
                   text: "Troubleshooting",
                   link: "/nodes/celestia-node-troubleshooting",
@@ -608,6 +612,10 @@ function sidebarHome() {
                           text: "Caldera",
                           link: "https://caldera.xyz/",
                         },
+                        {
+                          text: "Conduit",
+                          link: "https://conduit.xyz/",
+                        }
                       ],
                     },
 

.vitepress/constants/arabica_versions.js

@@ -1,9 +1,9 @@
 const arabicaVersions = Object.freeze({
-  "app-latest-tag": "v1.11.0",
-  "app-latest-sha": "21b5bc747c8500e4888474df7d828e66c33f332d",
-  "core-latest-tag": "v1.36.1-tm-v0.34.29",
-  "core-latest-sha": "624c43d4484a785ec855f5fb93ea571c1e728fda",
-  "node-latest-tag": "v0.14.0",
-  "node-latest-sha": "13439ccfebca67cc973cb7fa69570060e4540c13",
+  "app-latest-tag": "v2.1.2",
+  "app-latest-sha": "48173df3dc78f9348eedb3796f29ef9e9e5dc584",
+  "core-latest-tag": "v1.40.1-tm-v0.34.29-rc0",
+  "core-latest-sha": "0d2b63836d0f4587e162bfded58f53fba238e69c",
+  "node-latest-tag": "v0.16.0-rc0",
+  "node-latest-sha": "603288597fbd82c44aaa0a0ac8d187cac1860431",
 });
 export default arabicaVersions;

.vitepress/constants/constants.js

@@ -1,10 +1,10 @@
 const constants = Object.freeze({
-  golangNodeMainnet: "1.21.1",
+  golangNodeMainnet: "1.22.0",
   golangNodeMocha: "1.22.0",
   golangNodeArabica: "1.22.0",
   golangApp: "1.22.0",
   golangCore: "1.22.0",
-  golang: "1.21.1",
+  golang: "1.22.0",
   arabicaChainId: "arabica-11",
   mainnetChainId: "celestia",
   mochaChainId: "mocha-4",

.vitepress/constants/mainnet_versions.js

@@ -1,9 +1,9 @@
 const mainnetVersions = Object.freeze({
-  "app-latest-tag": "v1.11.0",
-  "app-latest-sha": "21b5bc747c8500e4888474df7d828e66c33f332d",
-  "core-latest-tag": "v1.37.0-tm-v0.34.29",
-  "core-latest-sha": "056df6caddb696d732d6513dc87c5dba529398d8",
-  "node-latest-tag": "v0.13.7",
-  "node-latest-sha": "0308aea76857ff27484946fce99004ebf10a3cb8",
+  "app-latest-tag": "v1.13.0",
+  "app-latest-sha": "d40b04b5d38399daf1c7108c1ecc0de4603d4852",
+  "core-latest-tag": "v1.40.1-tm-v0.34.29-rc0",
+  "core-latest-sha": "0d2b63836d0f4587e162bfded58f53fba238e69c",
+  "node-latest-tag": "v0.15.0",
+  "node-latest-sha": "b745c60deff7d339c773d77e6b350a4a338ac682",
 });
 export default mainnetVersions;

.vitepress/constants/mocha_versions.js

@@ -1,9 +1,9 @@
 const mochaVersions = Object.freeze({
-  "app-latest-tag": "v1.11.0",
-  "app-latest-sha": "21b5bc747c8500e4888474df7d828e66c33f332d",
-  "core-latest-tag": "v1.36.1-tm-v0.34.29",
-  "core-latest-sha": "624c43d4484a785ec855f5fb93ea571c1e728fda",
-  "node-latest-tag": "v0.14.0",
-  "node-latest-sha": "13439ccfebca67cc973cb7fa69570060e4540c13",
+  "app-latest-tag": "v2.1.2",
+  "app-latest-sha": "48173df3dc78f9348eedb3796f29ef9e9e5dc584",
+  "core-latest-tag": "v1.40.1-tm-v0.34.29-rc0",
+  "core-latest-sha": "0d2b63836d0f4587e162bfded58f53fba238e69c",
+  "node-latest-tag": "v0.16.0-rc0",
+  "node-latest-sha": "603288597fbd82c44aaa0a0ac8d187cac1860431",
 });
 export default mochaVersions;

community/foundation-delegation-program.md

@@ -83,6 +83,7 @@ compliance screen
 * Dedicated email address so that the Foundation can reach you in the event
 of emergency upgrades and fixes
 * Maintain a fully archival (non pruned) bridge node for both Mainnet Beta and Mocha if selected for the program
+* Not running your infrastructure in Hetzner or OVH 
 
 Not adhering to any of the criteria above will automatically disqualify your
 application, and violating any of the criteria after you have received
@@ -168,7 +169,7 @@ The Foundation will report each cohort’s composition and the duration of
 their respective delegations.
 
 * [Cohort 1](https://docs.google.com/spreadsheets/d/1Fxu9uYJ4wxfHChEiSg5bmXAMU8IZSq7J3GYDCFgk1HA/edit#gid=0): 50 Validator Seats
-* Cohort 2: 15 Validator Seats (Applications open June 1, 2024)
+* [Cohort 2](https://docs.google.com/spreadsheets/d/1Fxu9uYJ4wxfHChEiSg5bmXAMU8IZSq7J3GYDCFgk1HA/edit?gid=855157686#gid=855157686): 15 Validator Seats (Applications open June 1, 2024)
 * Cohort 3: 15 Validator Seats (Applications open October 1, 2024)
 * Cohort 4: 20 Validator Seats (Applications open February 1, 2025)
 

developers/arbitrum-integration.md

@@ -41,7 +41,8 @@ The core logic behind posting and retrieving data happens in [celestia.go](https
 Then the `Read` logic takes care of taking the deserialized Blob Pointer struct and consuming it in order to fetch the data from Celestia and additionally inform the fetcher about the position of the data on Celestia (we'll get back to this in the next section).
 
 The following represents a non-exhaustive list of considerations when running a Batch Poster node for a chain with Celestia underneath:
-- You will need to use a consensus full node RPC endpoint, you can find a list of them for Mocha [here](https://docs.celestia.org/nodes/mocha-testnet#rpc-endpoints)
+- You will need to use a consensus node RPC endpoint, you can
+[find a list of them for Mocha](../nodes/mocha-testnet#community-rpc-endpoints)
 - The Batch Poster will only post a Celestia batch to the underlying chain if the height for which it posted is in a recent range in BlobstreamX and if the verification succeeds, otherwise it will discard the batch. Since it will wait until a range is relayed, it can take several minutes for a batch to be posted, but one can always make an on-chain request for the BlobstreamX contract to relay a header promptly.
 
 The following represents a non-exhaustive list of considerations when running a Nitro node for a chain with Celestia underneath:

developers/blobstream-proof-queries.md

@@ -11,7 +11,7 @@ next:
 
 ## Prerequisites
 
-- Access to a Celestia [full consensus node](../nodes/full-consensus-node.md)
+- Access to a Celestia [consensus node](../nodes/consensus-node.md)
   RPC endpoint (or full node). The node doesn't need to be a
   validating node in order for the proofs to be queried. A full node is enough.
 

developers/blobstream-rollups.md

@@ -460,3 +460,29 @@ and
 The proof sizes are small and allow for greater flexibility.
 However, if the rollup team has different requirements, then the other designs
 can be explored.
+
+## FAQ
+
+### Should I use the Celestia transaction hash to reference the rollup data?
+
+This is asked a lot since it's the most intuitive way of referencing data.
+However, in Celestia, referencing the data using the transaction hash is not recommended.
+
+A transaction proof in Celestia goes back to providing an inclusion proof of the shares containing the transaction.
+This means if the transaction hash is used to reference data in a Celestia block, the rollup verification mechanism should
+do the following:
+
+- Verify an inclusion proof of the shares comprising the transaction up to the data root tuple root
+- Decode those shares and parse the transaction, then hash its components to generate the transaction hash
+- Verify that the generated transaction hash matches the one used to reference the data
+
+At this level, the transaction hash is authenticated and the verification contract has the
+shares of the transaction.
+Then, the verification contract needs to take the share commitment from the parsed transaction
+and follow the steps outlined in the [blob share commitment](#blob-share-commitment) section.
+
+As observed, using the transaction hash is expensive and doesn't yield any advantages
+over using the blob share commitment, which in turn is more expensive than using the sequence of spans.
+
+So, unless there are more reasons to use the transaction hash to reference the rollup data, the sequence of
+spans approach remains better.