From 24b34ecdc0c8a3ebfb4182b6bdfc7dc2a8a90ff6 Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Thu, 14 Nov 2024 08:15:50 +0100 Subject: [PATCH 01/11] fix typo --- docs/pages/concepts/micro-rollup/utility.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/pages/concepts/micro-rollup/utility.mdx b/docs/pages/concepts/micro-rollup/utility.mdx index a6916c5..8dbffad 100644 --- a/docs/pages/concepts/micro-rollup/utility.mdx +++ b/docs/pages/concepts/micro-rollup/utility.mdx @@ -2,7 +2,7 @@ Micro rollups offer a transformative approach for developing a broad spectrum of applications, essentially enhancing anything traditionally built as a smart contract on a blockchain. This paradigm shift not only promises an improved developer experience by abstracting away the complexities of Layer 1 blockchain intricacies but also allows developers to leverage their existing skills in a more familiar development environment. -Infact anything that can be built as a smart contract on a blockchain can be built better as a combination of MRU and a smart contract. +In fact anything that can be built as a smart contract on a blockchain can be built better as a combination of MRU and a smart contract. ## 1. Sidecars to existing protocols From 96d42829c36ef1a076a0e7a6c470034677d780c6 Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Thu, 14 Nov 2024 08:17:00 +0100 Subject: [PATCH 02/11] fix typo --- docs/pages/concepts/micro-rollup/motivation/modularity.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/pages/concepts/micro-rollup/motivation/modularity.mdx b/docs/pages/concepts/micro-rollup/motivation/modularity.mdx index 5bb813e..5e9ffb9 100644 --- a/docs/pages/concepts/micro-rollup/motivation/modularity.mdx +++ b/docs/pages/concepts/micro-rollup/motivation/modularity.mdx @@ -4,4 +4,4 @@ Stackr is a modular system, you can use whatever you want. We firmly believe tha ## Modular by design -External dependencies like sequencing, data availibility, settlement etc are customizable by the developers and they can choose to use anything they wish in the form of hot swappable modules. Stackr does not wish to lock the developers into a particular ecosystem and provides the ability to mix and match different tech stacks. +External dependencies like sequencing, data availability, settlement etc are customizable by the developers and they can choose to use anything they wish in the form of hot swappable modules. Stackr does not wish to lock the developers into a particular ecosystem and provides the ability to mix and match different tech stacks. From e32ef732f6b1321de5208a7bc4c290a40457cd16 Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Thu, 14 Nov 2024 08:17:22 +0100 Subject: [PATCH 03/11] fix typo --- .../concepts/micro-rollup/motivation/single-app-rollups.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/pages/concepts/micro-rollup/motivation/single-app-rollups.mdx b/docs/pages/concepts/micro-rollup/motivation/single-app-rollups.mdx index 88428ae..71a3ddf 100644 --- a/docs/pages/concepts/micro-rollup/motivation/single-app-rollups.mdx +++ b/docs/pages/concepts/micro-rollup/motivation/single-app-rollups.mdx @@ -1,6 +1,6 @@ # Single-App Rollups [Micro-Rollups are for standalone apps] -Micro-rollups are oprimized for **single-app rollups**. By providing each application with its dedicated rollup, this approach effectively removes the battle for shared state, thus alleviating congestion and minimizing transaction fees. +Micro-rollups are optimized for **single-app rollups**. By providing each application with its dedicated rollup, this approach effectively removes the battle for shared state, thus alleviating congestion and minimizing transaction fees. The core advantages of micro-rollups lie in their support for modular development and their ability to scale. From ace421e178669c6ba253ee2cc09ad8a5ae3b677a Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Thu, 14 Nov 2024 08:18:28 +0100 Subject: [PATCH 04/11] fix typos --- .../concepts/micro-rollup/motivation/traditional-rollups.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/pages/concepts/micro-rollup/motivation/traditional-rollups.mdx b/docs/pages/concepts/micro-rollup/motivation/traditional-rollups.mdx index fd2944a..1793102 100644 --- a/docs/pages/concepts/micro-rollup/motivation/traditional-rollups.mdx +++ b/docs/pages/concepts/micro-rollup/motivation/traditional-rollups.mdx @@ -28,4 +28,4 @@ Each app-specific rollup becomes an isolated environment, making it challenging The reliance on modified general-purpose languages does not fully escape the constraints and inefficiencies inherent to those systems. While customization can lead to improvements in certain areas, it often carries over the limitations and overhead of the underlying technology. As a result, app-specific rollups may still face issues related to scalability, flexibility, and developer accessibility, which they were meant to overcome. -In summary, while app-specific rollup environments represent a step towards addressing the one- size-fits-all dilemma of general-purpose rollups, they are not without their own set of challenges. The complexity of customization, ecosystem fragmentation, and inherited limitations of modified general- purpose languages suggest that a more fundamental rethinking of rollup technology is necessary to unlock the full potential of scalable, interoperable, and developer-friendly blockchain applications. +In summary, while app-specific rollup environments represent a step towards addressing the one-size-fits-all dilemma of general-purpose rollups, they are not without their own set of challenges. The complexity of customization, ecosystem fragmentation, and inherited limitations of modified general-purpose languages suggest that a more fundamental rethinking of rollup technology is necessary to unlock the full potential of scalable, interoperable, and developer-friendly blockchain applications. From bf592e5621d45dd125374467a8ba7f57d0756f25 Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Thu, 14 Nov 2024 08:19:00 +0100 Subject: [PATCH 05/11] fix typo --- .../concepts/micro-rollup/architecture/execution-layer.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/pages/concepts/micro-rollup/architecture/execution-layer.mdx b/docs/pages/concepts/micro-rollup/architecture/execution-layer.mdx index b218e44..b6025e9 100644 --- a/docs/pages/concepts/micro-rollup/architecture/execution-layer.mdx +++ b/docs/pages/concepts/micro-rollup/architecture/execution-layer.mdx @@ -6,4 +6,4 @@ The execution layer hosts the main application logic. This environment delivers ![Execution Model](/assets/execution-model.png) -MRUs deliver exceptionally high throughput, mirroring the instant interaction users expect from web2 applications. Upon receiving a user’s request, the application promptly attempts to execute the state changes. If successful, it instantly provides feedback to the user. Subsequently, in according to MRU configurations, the application dispatches the block containing the state update and the corresponding actions to the Vulcan layer. This layer is responsible for verifying the accuracy of the transactions before ultimately recording the data on the blockchain. +MRUs deliver exceptionally high throughput, mirroring the instant interaction users expect from web2 applications. Upon receiving a user’s request, the application promptly attempts to execute the state changes. If successful, it instantly provides feedback to the user. Subsequently, according to MRU configurations, the application dispatches the block containing the state update and the corresponding actions to the Vulcan layer. This layer is responsible for verifying the accuracy of the transactions before ultimately recording the data on the blockchain. From 2d63c2673ed997af452cc6f79aad9569cfddb8bb Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Thu, 14 Nov 2024 08:20:06 +0100 Subject: [PATCH 06/11] fix typos --- .../concepts/micro-rollup/architecture/verification-layer.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/pages/concepts/micro-rollup/architecture/verification-layer.mdx b/docs/pages/concepts/micro-rollup/architecture/verification-layer.mdx index 19bef0d..596822f 100644 --- a/docs/pages/concepts/micro-rollup/architecture/verification-layer.mdx +++ b/docs/pages/concepts/micro-rollup/architecture/verification-layer.mdx @@ -18,7 +18,7 @@ Therefore, Vulcan provides a flexible range of settlement-as-a-service options f Deployment flow Before Vulcan can start verifying blocks, the developer must first build out their Stackr State machine (SSM) and deploy it as a microrollup (execution layer). -The SSM is then compiled down to a WASM binary and sent to Vulcan, alongwith an initial genesis state. This all happens when executing the `deploy` CLI command. +The SSM is then compiled down to a WASM binary and sent to Vulcan, along with an initial genesis state. This all happens when executing the `deploy` CLI command. In the future, Vulcan will post the binary and genesis state to a DA layer to @@ -69,4 +69,4 @@ Vulcan behaves like a fast finality settlement layer, providing soft confirmatio Once an incoming block is verified, Vulcan will first ensure its availability by posting it to a DA layer of the developer's choice. This can be Avail, Celestia or EigenDA. After finalizing proof of data publication, Vulcan will emit a `C3A` confirmation event to denote guaranteed data availability and then proceed to submit the batch (a set of blocks) to the corresponding MRU's `AppInbox` smart contract on the parent chain. -On successful submission, the batch (a set of blocks) will be appended to the canonical chain on L1 and Vulcan will emit a `C3B` confirmation event denoting succesful settlement of the batch onchain. +On successful submission, the batch (a set of blocks) will be appended to the canonical chain on L1 and Vulcan will emit a `C3B` confirmation event denoting successful settlement of the batch onchain. From ca003f54038bf6b0d286f5c3b0d01d1fb6e26a96 Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Thu, 14 Nov 2024 08:24:15 +0100 Subject: [PATCH 07/11] fix typos --- docs/pages/build/changelog.mdx | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/pages/build/changelog.mdx b/docs/pages/build/changelog.mdx index 6b904f7..c1c5871 100644 --- a/docs/pages/build/changelog.mdx +++ b/docs/pages/build/changelog.mdx @@ -53,7 +53,7 @@ - The EIP-712 domain for the app is now injected into the `stf.wasm`. - Outputs the actual error message if any step in `compile` (or `deploy`) command fails. -- Fixes reading of leaf-level shorthand property assingments in `stackr.config.ts`. +- Fixes reading of leaf-level shorthand property assignments in `stackr.config.ts`. - Fixes using the `deploymentFile` property from `stackr.config.ts` for deployment file name if specified (defaults to `deployment.json`). ## v0.5.4 (and CLI v0.1.4) @@ -108,7 +108,7 @@ #### Breaking Changes -- Blocks are now rolled up into batches by Vulcan every some fixed interval. Therefore, C3A and above confirmation levels are now received on the batch level from Vulcan and L1. [Learn more](/build/framework/batch). +- Blocks are now rolled up into batches by Vulcan at every fixed interval. Therefore, C3A and above confirmation levels are now received on the batch level from Vulcan and L1. [Learn more](/build/framework/batch). - State Updates are now stored on the Block level and not Action level. In case of a chain revert, the state reverts to the last block having status equal to or higher than `Sequenced`. - Renamed `batchSize` and `batchTime` fields in `StackrConfig` to `blockSize` and `blockTime` respectively. @@ -237,7 +237,7 @@ Full Changelog: [v0.1.7...v0.2.0](https://github.com/stackrlabs/go-daash/compar 2. [SDK] Simplified State structure by dropping `clone` method from requirement and making WrappedState optional for trivial states. 3. [SDK] Type Safety on inputs in STF by adding `InputType` as optional second param to `STF` type. 4. [CLI] New Templates added for initialising a Micro-rollup. -5. [CLI ]initialise projects with basic `README.md` +5. [CLI] Initialise projects with basic `README.md` 6. [CLI] Add `chainId` to `deployment.json` making it easier for user to get Chain Information for Signing Domain 7. [CLI] Clean-up interim build files in process of making State Machine WASM 8. [SDK] Take `stateMachines` in MRU constructor. @@ -247,12 +247,12 @@ Full Changelog: [v0.1.7...v0.2.0](https://github.com/stackrlabs/go-daash/compar #### Fixes -1. [SDK] Fix duplication batch submission to Vulcan incase of high response times. +1. [SDK] Fix duplication batch submission to Vulcan in case of high response times. 2. [CLI] Sanitise URLs and payload before sending deployment requests to Parent Chain and Vulcan. 3. [CLI] Handle Registration with `falsy` Genesis states. 4. [SDK] Initialisation of Parent Chain listeners in `sandbox` Mode. [Lazy Initialisation] 5. [SDK] Serialisation of `bigint` entities to `number` before sending it in batch to Vulcan. -6. [VULCAN] Compare `primitve` and `non-primitive` Genesis States separately, to avoid serialisation causing validation failures. +6. [VULCAN] Compare `primitive` and `non-primitive` Genesis States separately, to avoid serialisation causing validation failures. ## v0.2.4-alpha to v0.2.11-alpha From 5360742af085e846f2d0119b5ad6f1d0e4124348 Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Thu, 14 Nov 2024 08:24:56 +0100 Subject: [PATCH 08/11] fix typo --- docs/pages/build/development-paradigm.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/pages/build/development-paradigm.mdx b/docs/pages/build/development-paradigm.mdx index ed38779..78306cd 100644 --- a/docs/pages/build/development-paradigm.mdx +++ b/docs/pages/build/development-paradigm.mdx @@ -4,11 +4,11 @@ Stackr is a blockchain development framework that provides a fresh perspective on decentralized app development. It takes away from the regular smart contract development paradigm and provides tooling that enables developers to inject their application logic directly into the blockchain. -In a way it is similar to Polkadot's [Substrate framework](https://substrate.io/), but with a focus on Ethereum L2s, specially single-app rollups which we call "Micro-Rollups". +In a way it is similar to Polkadot's [Substrate framework](https://substrate.io/), but with a focus on Ethereum L2s, especially single-app rollups which we call "Micro-Rollups". #### Build blockchains like apps -With Stackr, Developers dont write smart contracts, they build _state machines_. +With Stackr, Developers don't write smart contracts, they build _state machines_. They can define their state, actions, and state transition functions and the Stackr framework converts that into a blockchain. Stackr does not provide a VM that can run a smart contract. Instead, it provides a way to write state transition functions that contain the application logic. From 4ba5a0fb49a42790b5f6599ad3b0da64ef58e5b8 Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Thu, 14 Nov 2024 08:25:49 +0100 Subject: [PATCH 09/11] fix typo --- docs/pages/build/faq.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/pages/build/faq.mdx b/docs/pages/build/faq.mdx index 418ca2a..25f6649 100644 --- a/docs/pages/build/faq.mdx +++ b/docs/pages/build/faq.mdx @@ -11,7 +11,7 @@ Read our [Hosting guide](/build/guides/hosting) for more information. ::: :::details[Why is it taking so long to get C3A/C3B confirmation on my blocks?] -If you send in multiple blocks from your Micro-rollup, they will be ordered and rolled-up into a single block on Vulcan. Vulcan is configured to create batches every 6 hours or max blob size of chosen DA which ever comes first. +If you send in multiple blocks from your Micro-rollup, they will be ordered and rolled-up into a single block on Vulcan. Vulcan is configured to create batches every 6 hours or max blob size of chosen DA whichever comes first. Therefore, subsequent blocks will take more time to get C3A/C3B confirmation. It takes few minutes roughly how much time it takes to confirm data publication of the batch on a data availability layer. After this, depending on Sepolia's network congestion, it may take 10-30s to submit the batch to your app's inbox and receive C3B confirmation. From 5766d76eee005102fe6264261347e33ffa761248 Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Thu, 14 Nov 2024 08:27:26 +0100 Subject: [PATCH 10/11] fix typo --- docs/pages/build/guides/community-examples.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/pages/build/guides/community-examples.mdx b/docs/pages/build/guides/community-examples.mdx index 20f4bdd..e3be396 100644 --- a/docs/pages/build/guides/community-examples.mdx +++ b/docs/pages/build/guides/community-examples.mdx @@ -30,7 +30,7 @@ stAVL - Avail Liquid Staking Tokens ### [Stealth Micro-Rollup](https://github.com/Dhruv-2003/StealthMRU) -A Stealth Address -based privacy enabling micro rollup for all EVM blockchains. +A Stealth Address-based privacy enabling micro rollup for all EVM blockchains. ### [UTXO Micro-Rollup](https://github.com/Dhruv-2003/UTXO-rollup) From 1e481f110c9896824331a860ce1f079b7f9bb6b3 Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Thu, 14 Nov 2024 08:28:43 +0100 Subject: [PATCH 11/11] fix typo --- docs/pages/build/guides/tutorials/counter.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/pages/build/guides/tutorials/counter.mdx b/docs/pages/build/guides/tutorials/counter.mdx index b0665e3..5ad62b2 100644 --- a/docs/pages/build/guides/tutorials/counter.mdx +++ b/docs/pages/build/guides/tutorials/counter.mdx @@ -50,7 +50,7 @@ export class CounterState extends State { ``` :::info -The hashing function could be any function that takes the state as input and returns a hash determinitically. The hash should be a `BytesLike` type. +The hashing function could be any function that takes the state as input and returns a hash deterministically. The hash should be a `BytesLike` type. ::: ## Define State Transition Functions (STF)