From ee1dd2f3be081d066eb1d566573a6987b936d3e0 Mon Sep 17 00:00:00 2001 From: MSevey Date: Tue, 3 Sep 2024 13:35:21 +0000 Subject: [PATCH] deploy: b746bd0d6c8e997f3a4cd35f76edf90175a9c888 --- 404.html | 2 +- README.html | 2 +- blog/overview.html | 2 +- blog/rollkit-the-first-sovereign-rollup-framework.html | 2 +- blog/sovereign-rollups-on-bitcoin.html | 2 +- guides/block-times.html | 2 +- guides/connect-local-da.html | 2 +- guides/create-genesis.html | 2 +- guides/cw-orch.html | 2 +- guides/da-block-time.html | 2 +- guides/full-and-sequencer-node.html | 2 +- guides/gas-price.html | 2 +- guides/ibc-connection.html | 2 +- guides/lazy-sequencing.html | 2 +- guides/max-pending-blocks.html | 2 +- guides/overview.html | 2 +- guides/restart-rollup.html | 2 +- guides/rollkit-monitoring.html | 2 +- guides/use-rollkit-cli.html | 2 +- guides/use-tia-for-gas.html | 2 +- guides/zkml.html | 2 +- hashmap.json | 2 +- index.html | 2 +- learn/about.html | 2 +- learn/building-and-deploying-a-rollup.html | 2 +- learn/intro.html | 2 +- learn/specifications.html | 2 +- learn/stack.html | 2 +- learn/transaction-flow.html | 2 +- testnets/cosmwasm-testnet.html | 2 +- tutorials/artela-evm-plus-plus.html | 2 +- tutorials/avail-da.html | 2 +- tutorials/beaconkit.html | 2 +- tutorials/bitcoin.html | 2 +- tutorials/celestia-da.html | 2 +- tutorials/cosmwasm.html | 2 +- tutorials/evm-contract-interaction.html | 2 +- tutorials/gm-world-arabica-testnet.html | 2 +- tutorials/gm-world-mainnet.html | 2 +- tutorials/gm-world-mocha-testnet.html | 2 +- tutorials/gm-world.html | 2 +- tutorials/octane-evm.html | 2 +- tutorials/polaris-evm.html | 2 +- tutorials/quick-start.html | 2 +- tutorials/wordle.html | 2 +- 45 files changed, 45 insertions(+), 45 deletions(-) diff --git a/404.html b/404.html index 42ebceb83..97a893517 100644 --- a/404.html +++ b/404.html @@ -35,7 +35,7 @@

404

PAGE NOT FOUND

But if you don't change your direction, and if you keep looking, you may end up where you are heading.
- + \ No newline at end of file diff --git a/README.html b/README.html index 488af190e..6d1b281ca 100644 --- a/README.html +++ b/README.html @@ -60,7 +60,7 @@
On this page

Rollkit Documentation Site

Welcome to the official documentation repository for Rollkit.

Here you'll find comprehensive guides, tutorials, and reference materials to help you make the most out of Rollkit.

Building the site

To get started, clone the repository and run the following:

bash
yarn run docs:dev

This documentation site is built with VitePress

Contribution Guidelines

We love contributions from the community! Whether you're fixing typos, improving content clarity, or adding new topics, every contribution helps.

  • Fork & Clone: Fork this repository and clone it to your local machine.
  • Branch: Always create a new branch for your changes. Naming it relevantly.
  • Commit Changes: Make your changes and commit them with a clear and concise commit message.
  • Push & Create PR: Push your changes to your fork and create a pull request to the main branch of this repository.

Please ensure to review the detailed Contribution Guidelines above before making a pull request.

Directory Structure

  • /tutorials: Step-by-step instructions to help users build their own rollups with Rollkit.
  • /learn: Technical reference materials, such as configuration options and details about the Rollkit stack.
  • /blog: Blog posts for the Rollkit blog.
  • /public: Images, diagrams, and other media files used in the documentation.

Feedback & Suggestions

We value feedback from the community. If you have suggestions for improvements or find any discrepancies in the documentation, please raise an issue in this repository.

- + \ No newline at end of file diff --git a/blog/overview.html b/blog/overview.html index 5dc616463..19e2e369b 100644 --- a/blog/overview.html +++ b/blog/overview.html @@ -60,7 +60,7 @@
On this page

Blog

Welcome to our blog! Here, you'll find a variety of articles on a range of topics. Use this overview to navigate through our content.

Table of contents

Stay tuned for more exciting content!

- + \ No newline at end of file diff --git a/blog/rollkit-the-first-sovereign-rollup-framework.html b/blog/rollkit-the-first-sovereign-rollup-framework.html index 3a4e42aeb..6745777ff 100644 --- a/blog/rollkit-the-first-sovereign-rollup-framework.html +++ b/blog/rollkit-the-first-sovereign-rollup-framework.html @@ -62,7 +62,7 @@
On this page

Rollkit: The First Sovereign Rollup Framework

By Rollkit

Rollkit blog cover

Bitcoin to Ethereum took 7 years. Ethereum to more scalable alt-L1s took 1–2 years. And then Cosmos SDK and CometBFT brought down time-to-launch a sovereign L1 to months.

Now, Rollkit makes deploying any VM or application on its own sovereign chain as easy as typing rollkit start.

Rollkit provides a path to one-click sovereignty for any crypto application, enabling any developer to launch their own sovereign rollups within seconds.

Sovereign rollups combine the self-governance of a Layer 1 with the ease of deploying a rollup. They remove the need to recruit a secure validator set or bootstrap security by prematurely launching a token. Just like an independent L1, sovereign rollups retain the ability to hard fork which allows them to protect against hacks or bugs. This provides its community the ability to enforce social consensus and be sovereign.

Without the overhead of a settlement layer, sovereign rollups can directly interoperate with shared security when using the same DA layer.

By using a generic application interface like ABCI++, Rollkit is compatible with the Cosmos SDK, the leading framework for building sovereign blockchains. This enables all Cosmos SDK developers to build a sovereign rollup and tap into all the powerful cosmos ecosystem tooling they’re used to including IBC, ABCI++, and Skip Protocol's Slinky and BlockSDK.

Developers have full-freedom to deploy a VM or define their own execution environment, unconstrained by the overhead of an enshrined settlement layer that must process fraud or ZK proofs for their rollups. This means that instead of a canonical on-chain light client that comes with an enshrined settlement layer, sovereign rollups can define how they interoperate with other blockchains by having on-chain light clients of each other as needed.

Take Control

In the past, developers have been compelled to accept a degree of trust in convincing validators to organize and independently run nodes that secure a new blockchain. This requires launching premature tokens, inflating away their token supply in order to maintain incentive alignment with validators and offset their operational costs. This does not let developers focus on the core product they’re building. Sovereign rollups empower developers to get rid of this need to launch a token prematurely for bootstrapping a validator set and spending an excessively high amount of internal resources on blockchain development.

Existing settled rollups come with the overhead of an enshrined settlement layer like Ethereum L1 where it is difficult and expensive to unwind a token on an L2 and move to another L2 without relying on trusted liquidity bridging intermediaries. This also comes with becoming subordinate to the social consensus of an enshrined settlement layer, which they may or may not align with.

Sovereign rollups don’t need to settle to an external blockchain and can instead fully own their settlement. This allows them to protect against hacks and bugs, and facilitate upgrades via hard forks. They introduce rollup light clients that verify DA directly through data availability sampling and verify execution state proofs allowing asynchronous composability as needed. This in turn paves the path forward for trust-minimized interoperability between sovereign chains that share the same DA layer.

Sovereign rollups remove the need to have a bridge contract that is upgradeable by an offchain council and instead allows the sovereign community to define rules via fully onchain governance.

Build with the Best

Cosmos SDK’s rich array of developer tooling, battle-tested and refined over the past several years, is available to Rollkit developers from day one. Developers can use popular wallet infrastructure, block explorers and indexers supporting CometBFT RPCs, speak IBC across the interchain, have Cosmwasm smart contracts along with Abstract SDK, utilize MEV and free lanes via the BlockSDK and enshrine oracles in block production with Slinky from Skip Protocol. More cosmos related resources.

Rollkit rollups interact with a state machine via the Application Blockchain Interface (ABCI++). This allows it to be used as an alternative to CometBFT for any ABCI application. Rollkit comes with a custom start handler that can be used by Cosmos SDK blockchains to use it as its ABCI client while still following the release branches of upstream Cosmos SDK. This compatibility enables developers to use tools like abci-cli to test and debug rollups.

Optimize for your needs

Rollkit allows developers to optimize between the different modular components of a sovereign chain as needed. Rollkit allows you to:

  • Choose between data availability layers that implement the go-da interface.

  • Choose any ABCI++ compatible virtual machine.

  • Utilize the Sequencing API to delegate sequencing to the shared sequencer network of your choice or even delegate sequencing to the DA layer to go based. Choose between state validity modes: Pessimistic, Optimistic, or ZK or use a combination of both zk and optimistic schemes. Eliminate the need to launch a token or designate the native token or any token for gas fees.

  • Customize block time to just a couple hundred milliseconds and produce blocks only when needed.

  • Configure the fork choice rule.

Rollkit rollups pay only for data availability on demand. There is no sequencer split required, nor will there ever be any kind of rent seeking model imposed on Rollkit rollups. Rollkit rollups preserve the advantages of a Cosmos SDK blockchain but reduce the overhead of deploying and maintaining a validator set.

Break Free. Be Sovereign.

Get started with launching your own sovereign chain with Rollkit. If you’re thinking of building a sovereign chain, we’d love to hear from you. Fill out this form.

- + \ No newline at end of file diff --git a/blog/sovereign-rollups-on-bitcoin.html b/blog/sovereign-rollups-on-bitcoin.html index 5fbc0c6ed..e00255e7b 100644 --- a/blog/sovereign-rollups-on-bitcoin.html +++ b/blog/sovereign-rollups-on-bitcoin.html @@ -64,7 +64,7 @@
On this page

Sovereign rollups on Bitcoin with Rollkit

By Rollkit

rollkit-bitcoinOriginally published on 5 March 2023

Today, we are proud to announce that Rollkit is the first rollup framework to support sovereign rollups on Bitcoin. An early research implementation allows Rollkit rollups to use Bitcoin for data availability.

Rollkit is opening the door for developers to create rollups with arbitrary execution environments that inherit Bitcoin’s data availability guarantees and re-org resistance. With the new integration it is now possible to run the EVM on Bitcoin as a Rollkit sovereign rollup. Sovereign rollups on Bitcoin not only expand the possibilities for rollups, but also have the potential to help bootstrap a healthy blockspace fee market on Bitcoin, enabling a more sustainable security budget.

Tl;dr

  • Sovereign rollups using Bitcoin for data availability are now a reality with Rollkit’s new early research integration.
  • Follow along with a demo of the EVM running on Bitcoin as a sovereign Rollkit rollup.
  • The implementation was possible due to Bitcoin's Taproot upgrade and Ordinals' usage of Bitcoin for publishing arbitrary data.

Posting data on Bitcoin with Taproot

On Feb. 1, 2023, the Luxor mining pool mined the largest Bitcoin block (#774628) ever, approximately 4 MB. Most of the blockspace was used to inscribe a Taproot Wizards NFT with Ordinals, a project that implements NFTs on Bitcoin by publishing the image data on-chain.

Bitcoin NFTs use Taproot witnesses to inscribe arbitrary data, enabled by Bitcoin's Taproot upgrade. Taproot witnesses provide a slightly better payload-to-data ratio than SegWit transactions. A standard transaction can include up to around 390kB of arbitrary data while still passing through the public mempool. A non-standard transaction, included by a miner directly without passing through the mempool, can include close to 4MB of arbitrary data. In short, with SegWit, it became viable to post big blobs of data to the Bitcoin blockchain.

Since then, the usage of Ordinals for NFT inscriptions and Taproot utilization has kicked off. Eric Wall found that at the time of his tweet, posting data on Bitcoin was 7x cheaper than Ethereum. Now that there are thousands of inscriptions on Bitcoin, it has become clear that sovereign rollups and an ecosystem of dapps on Bitcoin could become a reality. The missing piece: a rollup framework for easily integrating Bitcoin as a data availability layer.

Integrating Bitcoin as a data availability layer into Rollkit

Rollkit is a modular framework for rollups, where developers can plug-in custom execution layers and data availability layers. Initially, Rollkit only supported Celestia as an option for data availability and consensus. Now, Bitcoin is an option, thanks to an early research implementation of a Bitcoin data availability module for Rollkit. In this case, sovereign rollups manage their own execution and settlement while offloading consensus and data availability to Bitcoin.

rollkit-bitcoin-rollup

How Rollkit posts data to Bitcoin

To write and read data on Bitcoin, we make use of Taproot transactions. To facilitate this, we implemented a Go package called bitcoin-da that provides a reader/writer interface to Bitcoin. For details of how the interface works and how it uses Taproot, see the specs. The package can be re-used by any project that wants to read or write data on Bitcoin.

Rollkit was built with modularity at its core. It has a data availability interface so that developers can simply implement specific methods to add a new data availability layer. To add a data availability layer, implementers need to satisfy the DataAvailabilityLayerClient interface which defines the behavior of the data availability client, and the BlockRetriever interface which defines how blocks can be synced. These interfaces live in the da package. The most important methods in these interfaces are SubmitBlock and RetrieveBlock for reading and writing the blocks.

After implementing the Taproot reader/writer interface for Bitcoin (bitcoin-da), adding it as a data availability module for Rollkit took less than a day. We mostly only had to implement the SubmitBlock and RetrieveBlocks functions for Rollkit to call the Read and Write methods in bitcoin-da.

rollkit-bitcoin-rollup-2

EVM on Bitcoin demo

Rollkit supports custom execution layers, including EVM, CosmWasm, or the Cosmos SDK. To test the integration, we used Rollkit to run the EVM (using Ethermint) as a sovereign rollup on a local Bitcoin test network. See below for a demo.

Conclusion

As we move towards a future where sovereign communities will form around different applications, asking them to incur the high cost and overhead of deploying a layer 1 blockchain to be sovereign is not sustainable. Sovereign rollups fix this by making it possible to deploy a sovereign chain that inherits the data availability and consensus of another layer 1 chain such as Bitcoin.

Our goal with Rollkit is to make it easy to build and customize rollups. We invite you to play around Rollkit and build sovereign rollups on Bitcoin, or customize Rollkit with different execution environments and data availability layers. For details on how to run Rollkit with the Bitcoin data availability module, see the instructions here. Keep in mind that the integration is an early research implementation and it is not yet production-ready!

Modularism, not maximalism.

Released under the APACHE-2.0 License

- + \ No newline at end of file diff --git a/guides/block-times.html b/guides/block-times.html index d99450ad2..093a88a99 100644 --- a/guides/block-times.html +++ b/guides/block-times.html @@ -62,7 +62,7 @@
On this page

How to change speed of block production

If you have gone through both the GM world and the Full and sequencer node rollup setup already, you're now ready to experiment with faster block times.

In your rollkit start [args...] command, you will need to add a flag and then the argument for block time.

The flag is:

bash
--rollkit.block_time 1s

Where 1s can be adjusted to the speed of your choosing.

Here is an example:

bash
# start the chain
 rollkit start [existing flags...] 
 rollkit start [existing flags...] --rollkit.block_time 1s 

In the above example, we've changed it to one second blocks. Alternatively, you could slow your rollup down to 30 seconds:

bash
--rollkit.block_time 30s

Or speed it up even more, to sub-second block times (100 milliseconds):

bash
--rollkit.block_time 100ms

Released under the APACHE-2.0 License

- + \ No newline at end of file diff --git a/guides/connect-local-da.html b/guides/connect-local-da.html index 8466f27e2..8313e5336 100644 --- a/guides/connect-local-da.html +++ b/guides/connect-local-da.html @@ -63,7 +63,7 @@
On this page

How to connect a rollup to a local DA network

This guide provides a quick and straightforward method to start a local Data Availability (DA) network and configure your rollup to post data to it.

Setting Up a Local DA Network

To set up a local DA network node on your machine, run the following script to install and start the local DA node:

bash
curl -sSL https://rollkit.dev/install-local-da.sh | bash -s v0.2.0

This script will build and run the node, which will then listen on port 7980.

Configuring your rollup to connect to the local DA network

To connect your rollup to the local DA network, you need to pass the --rollkit.da_address flag with the local DA node address.

Run your rollup

Start your rollup node with the following command, ensuring to include the DA address flag:

bash
rollkit start \
     --rollkit.da_address http://localhost:7980 \
     <other-flags>

Summary

By following these steps, you will set up a local DA network node and configure your rollup to post data to it. This setup is useful for testing and development in a controlled environment.

Released under the APACHE-2.0 License

- + \ No newline at end of file diff --git a/guides/create-genesis.html b/guides/create-genesis.html index 2b456a807..2d7810bbc 100644 --- a/guides/create-genesis.html +++ b/guides/create-genesis.html @@ -69,7 +69,7 @@ jq --argjson pubKey "$PUB_KEY" '.consensus["validators"]=[{"address": "'$ADDRESS'", "pub_key": $pubKey, "power": "1000", "name": "Rollkit Sequencer"}]' ~/.rollup/config/genesis.json > temp.json && mv temp.json ~/.rollup/config/genesis.json

10. Creating a restart script

Create a restart-rollup.sh file to restart the chain later, notice the rollkit.da_address flag which is the address of the data availability node, for other DA layers it will be a different set of flags (in case of Celestia check out the tutorial here):

sh
[ -f restart-rollup.sh ] && rm restart-rollup.sh
 
 echo "rollkit start --rollkit.aggregator --rpc.laddr tcp://127.0.0.1:36657 --grpc.address 127.0.0.1:9290 --p2p.laddr \"0.0.0.0:36656\" --minimum-gas-prices=\"0.025stake\" --rollkit.da_address \"http://localhost:7980\"" >> restart-rollup.sh

11. Starting the chain

Finally, start the chain with the following command:

sh
rollkit start --rollkit.aggregator --rpc.laddr tcp://127.0.0.1:36657 --grpc.address 127.0.0.1:9290 --p2p.laddr "0.0.0.0:36656" --minimum-gas-prices="0.025stake" --rollkit.da_address "http://localhost:7980"

Summary

By following these steps, you will set up the genesis for your rollup, initialize the validator, add a genesis account, and start the chain on a local data availability network (DA). This guide provides a basic framework for configuring and starting your rollup using the Rollkit CLI. Make sure rollkit.toml is present in the root of your rollup directory, and use the rollkit command for all operations.

Released under the APACHE-2.0 License

- + \ No newline at end of file diff --git a/guides/cw-orch.html b/guides/cw-orch.html index 9df7ebb8d..3cca2829e 100644 --- a/guides/cw-orch.html +++ b/guides/cw-orch.html @@ -150,7 +150,7 @@ ├── cw20_ics20.rs └── ..

When importing your crates to get the messages types, you can use the following command in the interface folder.

shell
cargo add cw20-base --path ../contracts/cw20-base/
 cargo add cw20 --path ../packages/cw20

Integrating single contracts

Now that you workspace is setup, you can integrate with single contracts using the above section

More examples and scripts

You can find more example interactions on the counter-contract example directly in the cw-orchestrator repo:

FINAL ADVICE: Learn more and explore our full cw-orch documentation !.

Released under the APACHE-2.0 License

- + \ No newline at end of file diff --git a/guides/da-block-time.html b/guides/da-block-time.html index f353d0c8b..3f29b5b19 100644 --- a/guides/da-block-time.html +++ b/guides/da-block-time.html @@ -61,7 +61,7 @@
On this page

How to configure DA chain block syncing time

The --rollkit.da_block_time flag is used to configure the time in seconds that the rollup will wait for a block to be synced from the DA chain.

bash
--rollkit.da_block_time duration

An example command would look like this:

bash
rollkit start [existing flags...] 
 rollkit start [existing flags...] --rollkit.da_block_time=30s 

Released under the APACHE-2.0 License

- + \ No newline at end of file diff --git a/guides/full-and-sequencer-node.html b/guides/full-and-sequencer-node.html index 377a1d7db..afb01a694 100644 --- a/guides/full-and-sequencer-node.html +++ b/guides/full-and-sequencer-node.html @@ -87,7 +87,7 @@ # use the auth token from that node AUTH_TOKEN=$(docker exec $(docker ps -q) celestia bridge auth admin --node.store /home/celestia/bridge)

Start the full node

Now run your full node with the script:

bash
# from the gm directory
 bash init-full-node.sh

Congratulations! You will now have a full node running alongside your Rollkit sequencer.

Released under the APACHE-2.0 License

- + \ No newline at end of file diff --git a/guides/gas-price.html b/guides/gas-price.html index e18aeb8e2..bac7bbb60 100644 --- a/guides/gas-price.html +++ b/guides/gas-price.html @@ -60,7 +60,7 @@
On this page

How to configure gas price

In most cases, the gas price can be left to the defaults, which ensures that the price is greater than the minimum gas price accepted by the core node.

The gas price can also be configured manually with the flag --rollkit.da_gas_price:

bash
rollkit start --rollkit.da_gas_price=0.1 [existing flags...]

This configures the rollup to always use the fixed gas price of 0.1utia/gas.

When running a rollup against a live network, the gas price may see occasional spikes during periods of high mempool congestion.

To avoid such transient blob submission failures, the flag --rollkit.da_gas_multiplier may be used:

bash
rollkit start --rollkit.da_gas_price=0.1 --rollkit.da_gas_multiplier=1.2 [...]

This configures the rollup to keep increasing the gas price by a factor of 1.2x of the previous price until the transaction is accepted by the core node.

When the blob submission transaction eventually succeeds, the gas price will gradually return to the default, decreasing by the same factor.

The gas multiplier will only be used if the gas price has been manually configured.

Released under the APACHE-2.0 License

- + \ No newline at end of file diff --git a/guides/ibc-connection.html b/guides/ibc-connection.html index 6b8f916d3..f1c69c50b 100644 --- a/guides/ibc-connection.html +++ b/guides/ibc-connection.html @@ -166,7 +166,7 @@ denom: stake pagination: total: "1"

Released under the APACHE-2.0 License

- + \ No newline at end of file diff --git a/guides/lazy-sequencing.html b/guides/lazy-sequencing.html index 18ac3c488..0adb3c8cd 100644 --- a/guides/lazy-sequencing.html +++ b/guides/lazy-sequencing.html @@ -62,7 +62,7 @@
On this page

How to Use Lazy Sequencing (Aggregation)

In this guide, we'll go over how to use lazy sequencing.

This feature was introduced in Rollkit v0.7.0 (with custom buffer time later in v0.13.7) and allows rollup operators to wait for transactions before building blocks. This prevents the rollup from building empty blocks.

To turn on lazy sequencing, add the following flag to your start command:

bash
--rollkit.lazy_aggregator

Additionally, if you want to specify the time interval used for block production even if there are no transactions, use:

bash
--rollkit.lazy_block_time <duration>

An example command with a custom block time of 1 minute:

bash
# start the chain
 rollkit start [existing flags...] 
 rollkit start [existing flags...] --rollkit.lazy_aggregator --rollkit.lazy_block_time=1m0s 

Released under the APACHE-2.0 License

- + \ No newline at end of file diff --git a/guides/max-pending-blocks.html b/guides/max-pending-blocks.html index fae6255e6..fcb4375e9 100644 --- a/guides/max-pending-blocks.html +++ b/guides/max-pending-blocks.html @@ -61,7 +61,7 @@
On this page

How to configure the maximum number of blocks pending DA submission

The --rollkit.max_pending_blocks flag is used to configure the maximum limit of blocks pending DA submission (0 for no limit)

bash
--rollkit.max_pending_blocks uint

An example command would look like this:

bash
rollkit start [existing flags...] 
 rollkit start [existing flags...] --rollkit.max_pending_blocks=100 

Released under the APACHE-2.0 License

- + \ No newline at end of file diff --git a/guides/overview.html b/guides/overview.html index b344b2e72..c56e2483d 100644 --- a/guides/overview.html +++ b/guides/overview.html @@ -60,7 +60,7 @@
On this page

How To Guides

Welcome to the Rollkit guides section! Here, you'll find a wide range of guides designed to help you understand and effectively use Rollkit, the first sovereign rollup framework.

Hopefully you've gone through some of the tutorials and are ready to dive deeper. These guides will go into detail on some specific topics that will make your life easier when developing with Rollkit.

In this section, you'll find:

💻 Support

The guides will explore developing with Rollkit, which is still in Alpha stage. If you run into bugs, please write a GitHub issue or let us know in our Telegram.

Released under the APACHE-2.0 License

- + \ No newline at end of file diff --git a/guides/restart-rollup.html b/guides/restart-rollup.html index 8e4d2229f..03ddd48bb 100644 --- a/guides/restart-rollup.html +++ b/guides/restart-rollup.html @@ -72,7 +72,7 @@ 4:51PM ERR DA layer submission failed Error="Codespace: 'sdk', Code: 19, Message: " attempt=2 module=BlockManager 4:51PM ERR DA layer submission failed error="Codespace: 'sdk', Code: 19, Message: " attempt=3 module=BlockManager

💰 Re-fund your account

First, you'll need to send more tokens to the account running your Celestia node. If you didn't keep track of your key, you can run the following to get your address:

bash
cd $HOME && cd celestia-node
 ./cel-key list --keyring-backend test --node.type light --p2p.network <network>

🛑 Stopping your rollup

You can stop your gm chain (or other Rollkit rollup) by using Control + C in your terminal where the node is running.

⛽ Increase the gas fee

To reiterate, before restarting the chain, you will need to increase the gas fee in order to avoid a Code: 19 error:

bash
rollkit start --rollkit.aggregator --rollkit.da_auth_token=$AUTH_TOKEN --rollkit.da_namespace $NAMESPACE --rollkit.da_start_height $DA_BLOCK_HEIGHT --rpc.laddr tcp://127.0.0.1:36657 --grpc.address 127.0.0.1:9290 --p2p.laddr "0.0.0.0:36656"

🔁 Restarting your rollup

Follow the restart rollup section above.

🛢️ Reduce gas fee & restart again

In order to save your TIA, we also recommend stopping the chain with Control + C, changing the gas fee back to the default (in our case, 8000 utia) and restarting the chain:

bash
rollkit start --rollkit.aggregator --rollkit.da_auth_token=$AUTH_TOKEN --rollkit.da_namespace $NAMESPACE --rollkit.da_start_height $DA_BLOCK_HEIGHT --rpc.laddr tcp://127.0.0.1:36657 --grpc.address 127.0.0.1:9290 --p2p.laddr "0.0.0.0:36656"

🎊 Congrats! You've successfully restarted your Rollkit rollup after running out of TIA.

Released under the APACHE-2.0 License

- + \ No newline at end of file diff --git a/guides/rollkit-monitoring.html b/guides/rollkit-monitoring.html index 6d805525f..bcde5c918 100644 --- a/guides/rollkit-monitoring.html +++ b/guides/rollkit-monitoring.html @@ -60,7 +60,7 @@
On this page

How to integrate Range with your rollup

This section illustrates how Rollkit developers can leverage the Range platform to monitor their rollup activity and explore relevant addresses and transactions in less than 5 minutes.

Overview

In this guide, we’ll go over the steps of the integration of our sample rollup GM, which is divided into three sections:

  1. Integrate your rollup with Range and start the indexing.
  2. Add your addresses and contracts.
  3. Create your first alert and explore transactions.

Prerequisites

You need to have an operational rollkit rollup. If you haven't done so, you'll need to complete the GM world tutorial first.

1. Integrate Your Rollup

We’ll integrate our rollup GM into Range and start indexing blocks and transactions in real-time.

custom-network

Steps

  • Create an account in Range
  • Make sure you have a public RPC endpoint of your Rollkit rollup
  • Go to the settings tab on your account profile in the top-right corner
  • Click the Add Network button in the Custom Network section
  • Choose Rollkit and fill out the form
  • Congrats! Your rollup should be integrated in Range in less than 15 seconds.

2. Add Your Addresses and Contracts

Now that your rollup is integrated into Range, you can customize your workspace. The first step is adding addresses and contracts that you want to monitor. For that, head to the Address section:

import-address

Once you’ve added one or multiple addresses, you can start looking at the real-time transactions explorer in the Transactions tab.

3. Creating Your First Alert Rule

Now, you can set up alerts to monitor specific events or transactions in your rollup. As an example, we can create an alert that notifies us every time our address is involved in a successful transaction:

alert-rules

After executing a sample transaction:

bash
gmd tx bank send gm-991hesf7xgmjwttag2n2wzk43rvxh47nn4ckh3e6s gm-991rcctqc5l4px95k6tdg4pjrms70m2a9t35rl50t 4039stake --keyring-backend test --node tcp://127.0.0.1:36657 --chain-id gm --fees 5000stake

The alert events will appear both in the Overview tab and the Alerting section:

alert-events

🎊 Congrats! You've detected the first monitored transaction in your GM rollup.

Released under the APACHE-2.0 License

- + \ No newline at end of file diff --git a/guides/use-rollkit-cli.html b/guides/use-rollkit-cli.html index 138f8ee18..07b551afa 100644 --- a/guides/use-rollkit-cli.html +++ b/guides/use-rollkit-cli.html @@ -71,7 +71,7 @@ rollkit tx # for any <rollup>d <command> rollkit <command>

Summary

By following these steps, you can install the Rollkit CLI, initialize the rollkit.toml configuration file, and run rollup commands. This setup helps you manage and interact with your rollup project efficiently.

Released under the APACHE-2.0 License

- + \ No newline at end of file diff --git a/guides/use-tia-for-gas.html b/guides/use-tia-for-gas.html index 67aa1ee8c..76ed4771d 100644 --- a/guides/use-tia-for-gas.html +++ b/guides/use-tia-for-gas.html @@ -186,7 +186,7 @@ # Verify success rollkit q tx "$TX_HASH" --output json | jq .code # => 0

🎉 Next steps

Congratulations! You've built a local rollup that posts to a local DA network and uses TIA as the gas token!

Released under the APACHE-2.0 License

- + \ No newline at end of file diff --git a/guides/zkml.html b/guides/zkml.html index 446669d98..05fc0f515 100644 --- a/guides/zkml.html +++ b/guides/zkml.html @@ -145,7 +145,7 @@ transactionIndex 0 type 2 to 0x5C59C83c099F72FcE832208f96a23a1E43737a14

TIP

Note: To see the decoded output of the contract call (to check if the proof was verified), you will need to view the call in a block explorer.

Congratulations

Congratulations, you've just verified a zkML circuit on Rollkit.

For further reading, check out Sindri's blog post explaining how using Sindri + Rollkit x Celestia means verifiable ML doesn’t have to be prohibitively expensive for operators or end users.

Released under the APACHE-2.0 License

- + \ No newline at end of file diff --git a/hashmap.json b/hashmap.json index 49c5f3519..e7116adca 100644 --- a/hashmap.json +++ b/hashmap.json @@ -1 +1 @@ -{"blog_overview.md":"e6d8d84a","blog_rollkit-the-first-sovereign-rollup-framework.md":"4b866691","guides_da-block-time.md":"b6e92aa8","tutorials_avail-da.md":"44b9751e","readme.md":"3e9aee85","learn_intro.md":"848d23dd","blog_sovereign-rollups-on-bitcoin.md":"8ea257c6","guides_use-tia-for-gas.md":"eb2bb76f","guides_full-and-sequencer-node.md":"abd7dadf","index.md":"392e0b88","guides_create-genesis.md":"98c28b1f","learn_about.md":"b99a8db6","guides_gas-price.md":"43ad859c","guides_max-pending-blocks.md":"dad49a6d","guides_restart-rollup.md":"946bbf36","tutorials_artela-evm-plus-plus.md":"786cd4e0","guides_use-rollkit-cli.md":"77720a6b","guides_connect-local-da.md":"4a773709","guides_block-times.md":"01ea5cf3","tutorials_bitcoin.md":"980ff476","guides_rollkit-monitoring.md":"8c1992cb","learn_stack.md":"a421626c","tutorials_celestia-da.md":"3929e1d9","guides_overview.md":"d25f26d1","guides_lazy-sequencing.md":"725b0ee8","guides_cw-orch.md":"829e1472","learn_building-and-deploying-a-rollup.md":"0ea9d744","tutorials_evm-contract-interaction.md":"1fbbeb93","learn_transaction-flow.md":"9fd98839","tutorials_beaconkit.md":"0b2b2247","testnets_cosmwasm-testnet.md":"19e28164","learn_specifications.md":"24a334f7","tutorials_gm-world-mainnet.md":"a9c27a10","tutorials_gm-world-mocha-testnet.md":"908e3c50","tutorials_gm-world-arabica-testnet.md":"ba5d2fe2","tutorials_polaris-evm.md":"f38e59ec","tutorials_octane-evm.md":"7957c24e","tutorials_quick-start.md":"1695dfda","tutorials_cosmwasm.md":"e829db55","tutorials_gm-world.md":"a559499a","guides_ibc-connection.md":"1b8fa4c6","guides_zkml.md":"5a9c66ec","tutorials_wordle.md":"21bd5c99"} +{"readme.md":"3e9aee85","blog_overview.md":"e6d8d84a","blog_rollkit-the-first-sovereign-rollup-framework.md":"4b866691","guides_full-and-sequencer-node.md":"abd7dadf","learn_building-and-deploying-a-rollup.md":"0ea9d744","guides_lazy-sequencing.md":"725b0ee8","learn_stack.md":"a421626c","guides_overview.md":"d25f26d1","guides_max-pending-blocks.md":"dad49a6d","testnets_cosmwasm-testnet.md":"19e28164","tutorials_artela-evm-plus-plus.md":"786cd4e0","learn_transaction-flow.md":"9fd98839","guides_use-rollkit-cli.md":"77720a6b","blog_sovereign-rollups-on-bitcoin.md":"8ea257c6","guides_da-block-time.md":"b6e92aa8","learn_intro.md":"848d23dd","index.md":"392e0b88","guides_connect-local-da.md":"4a773709","tutorials_bitcoin.md":"980ff476","guides_cw-orch.md":"829e1472","guides_restart-rollup.md":"946bbf36","guides_rollkit-monitoring.md":"8c1992cb","guides_zkml.md":"5a9c66ec","guides_block-times.md":"01ea5cf3","guides_create-genesis.md":"98c28b1f","guides_use-tia-for-gas.md":"eb2bb76f","learn_about.md":"b99a8db6","guides_gas-price.md":"43ad859c","tutorials_beaconkit.md":"0b2b2247","tutorials_avail-da.md":"44b9751e","tutorials_celestia-da.md":"3929e1d9","learn_specifications.md":"24a334f7","guides_ibc-connection.md":"1b8fa4c6","tutorials_quick-start.md":"1695dfda","tutorials_gm-world-mainnet.md":"a9c27a10","tutorials_gm-world-arabica-testnet.md":"ba5d2fe2","tutorials_cosmwasm.md":"e829db55","tutorials_octane-evm.md":"7957c24e","tutorials_gm-world-mocha-testnet.md":"908e3c50","tutorials_polaris-evm.md":"f38e59ec","tutorials_gm-world.md":"a559499a","tutorials_evm-contract-interaction.md":"1fbbeb93","tutorials_wordle.md":"21bd5c99"} diff --git a/index.html b/index.html index 941b88dd3..eecb73c28 100644 --- a/index.html +++ b/index.html @@ -60,7 +60,7 @@

Released under the APACHE-2.0 License

- + \ No newline at end of file diff --git a/learn/about.html b/learn/about.html index afa2551f3..ccda23566 100644 --- a/learn/about.html +++ b/learn/about.html @@ -60,7 +60,7 @@
On this page

About Rollkit

Our mission is allow anyone to launch their own sovereign, customizable blockchain as easily as a smart contract by utilizing the shared security of a modular data availability network.

TIP

In order to use Rollkit, it's important to have some familiarity with Cosmos SDK. You can get up to speed on Cosmos SDK by visiting their official documentation page.

If you're familiar with Rollkit, you may want to skip to the tutorials section.

What is Rollkit?

Rollkit is a sovereign rollup framework that gives developers the freedom to deploy rollups throughout the modular stack, opening new possibilities for rapid experimentation and innovation.

Read more on the Celestia blog to learn more about the concept of sovereign rollups.

Rollkit is an open-source framework. It features a modular node that can run rollups and exposes an ABCI-compatible client interface, which can be used as a substitute for CometBFT in any ABCI-compatible blockchain application.

Rollkit uses data availability (DA) layers by having a unified client interface which can be implemented for use with different DA networks, such as Celestia.

Our goal is to empower developers to quickly innovate and create new classes of rollups with minimal trade-offs, and to make deploying a new chain as easy as deploying a smart contract.

What problems is Rollkit solving?

1. Scalability and customizability

Deploying your decentralized application as a smart contract on a shared blockchain has many limitations. Your smart contract has to share computational resources with every other application, so scalability is limited.

Plus, you're restricted to the execution environment that the shared blockchain uses, so developer flexibility is limited.

2. Security and time to market

Deploying a new chain might sound like the perfect solution for the problems listed above. While it's somewhat true, deploying a new layer 1 chain presents a complex set of challenges and trade-offs for developers looking to build blockchain products.

Deploying a new layer 1 requires significant resources, including time, capital, and expertise, which can be a barrier to entry for some developers.

In order to secure the network, developers must bootstrap a sufficiently secure set of validators, incurring the overhead of managing a full consensus network. This requires paying validators with inflationary tokens, putting the business sustainability of the network at risk. A strong community and network effect are also critical for success, but can be challenging to achieve as the network must gain widespread adoption to be secure and valuable.

In a potential future with millions of chains, it's unlikely all of those chains will be able to sustainably attract a sufficiently secure and decentralized validator set.

Why Rollkit?

Rollkit solves the challenges encountered during the deployment of a smart contract or a new layer 1, by minimizing these tradeoffs through the implementation of rollup chains (rollups).

With Rollkit, developers can benefit from:

  • Shared security: Rollups inherit security from a data availability layer, by posting blocks to it. Rollups reduce the trust assumptions placed on rollup sequencers by allowing full nodes to download and verify the transactions in the blocks posted by the sequencer. For optimistic or zk rollups, in case of fraudulent blocks, full nodes can generate fraud or zk proofs, which they can share with the rest of the network, including light nodes. Our roadmap includes the ability for light clients to receive and verify proofs, so that everyday users can enjoy high security guarantees.

  • Scalability: Rollkit rollups are deployed on specialized data availability layers like Celestia, which directly leverages the scalability of the DA layer. Additionally, rollup transactions are executed off-chain rather than the data availability layer. This means rollups have their own dedicated computational resources, rather than sharing computational resources with other applications.

  • Customizability: Rollkit is built as an open source modular framework, to make it easier for developers to reuse the four main components and customize their rollups. These components are data availability layers, execution environments, proof systems, and sequencer schemes. The components used by the Rollkit stack are customizable.

  • Faster time to market: Rollkit eliminates the need to bootstrap a validator set, manage a consensus network, incur high economic costs, and face other trade-offs that come with deploying a new layer 1. Rollkit's goal is to make deploying a rollup as easy as it is to deploy a smart contract, cutting the time it takes to bring blockchain products to market from months or even years to just minutes.

  • Sovereignty: Rollkit also enables developers to deploy sovereign rollups for cases where communities require sovereignty.

How can you use Rollkit?

As briefly mentioned above, Rollkit could be used in many different ways. From sovereign rollups, to settlement layers, and in the future even to L3s.

Rollup with any execution environment

Rollkit gives developers the flexibility to use pre-existing ABCI-compatible state machines or create a custom state machine tailored to their rollup needs. Rollkit does not restrict the use of any specific virtual machine, allowing developers to experiment and bring innovative applications to life.

Sovereign rollup with Cosmos SDK

Similarly to how developers utilize the Cosmos SDK to build a sovereign layer 1 chain, the Cosmos SDK could be utilized to create a Rollkit-compatible rollup chain. Cosmos-SDK has great documentation and tooling that developers can leverage to learn.

Another possibility is taking an existing layer 1 built with the Cosmos SDK and deploying it as a Rollkit rollup. This can provide a great opportunity for experimentation and growth.

Build a settlement layer

Settlement layers are ideal for developers who want to avoid deploying sovereign rollups. They provide a platform for rollups to verify proofs and resolve disputes. Additionally, they act as a hub for rollups to facilitate trust-minimized token transfers and liquidity sharing between rollups that share the same settlement layer. Think of settlement layers as a special type of execution layer.

When can you use Rollkit?

As of today, Rollkit is still in the alpha stage. The framework currently provides a centralized sequencer, an execution interface (ABCI or Cosmos SDK), and a connection to a data availability layer.

We're currently working on implementing many new and exciting features such as light nodes and state fraud proofs.

Head down to the next section to learn more about what's coming for Rollkit. If you're ready to start building, you can skip to the Tutorials section.

Spoiler alert, whichever you choose, it's going to be a great rabbit hole!

Released under the APACHE-2.0 License

- + \ No newline at end of file diff --git a/learn/building-and-deploying-a-rollup.html b/learn/building-and-deploying-a-rollup.html index 2d23d8ca6..b6f2dc4d9 100644 --- a/learn/building-and-deploying-a-rollup.html +++ b/learn/building-and-deploying-a-rollup.html @@ -60,7 +60,7 @@
On this page

🗞️ Building a rollup and testnet deployment

The following tutorials will help you get started building Cosmos-SDK and EVM applications that connect to Celestia's data availability (DA) layer via Rollkit to Celestia's Mocha testnet or Arabica devnet. We call those chains Sovereign Rollups.

You can get started with the following tutorials:

1. Beginner

2️. Intermediate

3️. Advanced

💻 Support

The tutorials will explore developing with Rollkit, which is still in Alpha stage. If you run into bugs, please write a GitHub issue or let us know in our Telegram. Furthermore, while Rollkit allows you to build sovereign rollups on Celestia, it currently does not support fraud proofs yet and is therefore running in "pessimistic" mode, where nodes would need to re-execute the transactions to check the validity of the chain (i.e. a full node). Furthermore, Rollkit currently only supports a single sequencer.

Released under the APACHE-2.0 License

- + \ No newline at end of file diff --git a/learn/intro.html b/learn/intro.html index e5914e301..3cd157da2 100644 --- a/learn/intro.html +++ b/learn/intro.html @@ -60,7 +60,7 @@
On this page

Introduction

Welcome to the Rollkit docs. We're happy you made it here! Our mission is to allow anyone to launch their own sovereign, customizable blockchain as easily as a smart contract by utilizing the shared security of a modular data availability network.

Rollkit is the first sovereign rollup framework.

Our mission is allow anyone to launch their own sovereign, customizable blockchain as easily as a smart contract by utilizing the shared security of a modular data availability network.

We're setting the bar high for developers' flexibility and ability to customize rollups however they see fit.

Released under the APACHE-2.0 License

- + \ No newline at end of file diff --git a/learn/specifications.html b/learn/specifications.html index 32f583823..c68817715 100644 --- a/learn/specifications.html +++ b/learn/specifications.html @@ -60,7 +60,7 @@
On this page

Technical specifications

Rollkit specifications - is comprehensive documentation on the inner components of Rollkit, including data storage, transaction processing, and more. It’s an essential resource for developers looking to understand, contribute to and leverage the full capabilities of Rollkit.

Released under the APACHE-2.0 License

- + \ No newline at end of file diff --git a/learn/stack.html b/learn/stack.html index 5c8725917..c4e7d7c7e 100644 --- a/learn/stack.html +++ b/learn/stack.html @@ -60,7 +60,7 @@
On this page

Rollkit stack

This page will cover the main components of Rollkit.

Rollup sequencer nodes collect transactions from users, aggregate them into blocks, and post the blocks onto a data availability (DA) layer (such as Celestia) to be ordered and finalized. Full nodes execute and verify rollup blocks, and in the case of an optimistic rollup, propagate fraud proofs when needed. Light clients will receive headers, verify proofs (fraud, zk, etc), and authenticate trust-minimized queries about the state.

Application structure

null

ABCI interface

Rollkit is a fully functional Application BlockChain Interface (ABCI) client software. It can be used as a CometBFT replacement for any ABCI application. Thanks to this compatibility, you can use tools like abci-cli to test and debug your rollup.

Cosmos SDK

Would you like to change your Cosmos SDK application to a Rollkit rollup? No problem! You need to replace the Cosmos SDK Go dependency with a Rollkit-enabled version, which can be found at the rollkit/cosmos-sdk repository.

Note the rollkit/cosmos-sdk repository follows the release branches of upstream Cosmos SDK, but with the bonus of using Rollkit instead of CometBFT as the ABCI client.

And don't forget to replace another dependency, CometBFT, with rollkit/cometbft, which has an enhanced ABCI interface that includes the methods needed for state fraud proofs.

Data availability

Data availability (DA) can be accessed using generic interfaces. This design allows for seamless integration with any DA layer. New implementations can be plugged in programmatically, without a need to fork Rollkit.

The DataAvailabilityLayerClient interface includes essential lifecycle methods (Init, Start, Stop) as well as data availability methods (SubmitBlocks, RetrieveBlocks).

The BlockRetriever interface serves to enable syncing of full nodes from the data availability layer. It's important to keep in mind that there is no direct correlation between the DA layer block height and the rollup height. Each DA layer block may contain an arbitrary number of rollup blocks.

Celestia

Celestia is a prominent example of a data availability integration implemented for Rollkit. It's using the Celestia Node API via the rollkit/celestia-da package. To deploy a Rollkit rollup on Celestia you also have to run a Celestia light node.

New DA layer integrations can be added by using the go-da interface.

Node components

Mempool

The mempool is inspired by the CometBFT mempool. By default, transactions are handled in a First Come, First Served (FCFS) manner. Ordering of transactions can be implemented on the application level; currently this is possible by returning a priority on CheckTx, and once we support ABCI++ it is also possible via PrepareProposal and the application mempool.

Block manager

The block manager contains routines AggregationLoop, RetrieveLoop, and SyncLoop that communicate through Go channels. These Go routines are ran when a Rollkit node starts up (OnStart). Only the sequencer nodes run AggregationLoop which controls the frequency of block production for a rollup with a timer as per the BlockTime in BlockManager.

All nodes run SyncLoop which looks for the following operations:

  • Receive block headers: block headers are received through a channel HeaderInCh and Rollkit nodes attempt to verify the block with the corresponding block data.
  • Receive block data: block bodies are received through a channel blockInCh and Rollkit nodes attempt to verify the block.
  • Signal RetrieveLoop with timer as per the DABlockTime in BlockManager.

All nodes also run RetrieveLoop which is responsible for interacting with the data availability layer. It checks the last updated DAHeight to retrieve a block with timer DABlockTime signaled by SyncLoop. Note that the start height of the DA layer for the rollup, DAStartHeight, is configurable in BlockManager.

RPC

Rollkit's RPC fully implements the CometBFT RPC interfaces and APIs for querying:

  • Information about the rollup node: information such as node's health, status, and network info.
  • The rollup blockchain: getting information about the rollup blockchain such as blocks and block headers.
  • The rollup transactions: getting transaction information and broadcasting raw transactions, with search capabilities.
  • ABCI: rollup application information.

The following RPC protocols are currently supported:

  • URI over HTTP
  • JSON-RPC over HTTP
  • JSON-RPC over WebSockets

P2P layer

Rollkit's P2P layer enables direct communication between rollup nodes. It's used to gossip transactions, headers of newly created blocks, and state fraud proofs. The P2P layer is implemented using libp2p.

Rollkit uses DHT-based active peer discovery. Starting a node connects to pre-configured bootstrap peers, and advertises its namespace ID in the DHT. This solution is flexible, because multiple rollup networks may reuse the same DHT/bootstrap nodes, but specific rollup network might decide to use dedicated nodes as well.

Rollkit node types

Rollkit nodes are implemented in the node package.

Full node

Full nodes verify all blocks, and produce fraud proofs for optimistic rollups. Since they fully verify all rollup blocks, they don't rely on fraud or validity proofs for security.

Light node (work in progress)

Light nodes are light-weight rollup nodes that authenticate block headers, and can be secured by fraud proofs or validity proofs. They're recommended for average users on low-resource devices. Users running light nodes can make trust-minimized queries about the rollup's state. Currently, Rollkit light nodes are still under development.

Sequencer node

Rollups can utilize sequencer nodes. Sequencers are block producers for rollups, responsible for aggregating transactions into blocks, and typically executing transactions to produce a state root, used by the rollup's light clients.

Rollkit plans to support multiple different pluggable sequencer schemes:

Deploy in one-clickFaster soft-confirmations than L1Control over rollup's transaction orderingAtomic composability with other rollupsCensorship resistanceImplementation Status
Centralized sequencerRequires spinning up a sequencerYes ✅Yes ✅No ❌Eventual ⏳*✅ Implemented!
Decentralized sequencerRequires spinning up a sequencer setYes ✅Yes ✅No ❌Real-time ⚡️Planned
Shared decentralized sequencerYes ✅Yes ✅No ❌Yes ✅Real-time ⚡️Planned
Pure fork-choice ruleYes ✅No ❌Maybe 🟡Maybe 🟡Eventual ⏳Planned

"Pure fork-choice rule" refers to any rollup without privileged sequencers, e.g. nodes defer to the data availability layer for ordering and apply a "first-come-first-serve" fork-choice rule.

* implementation of this property is in progress.

State validity modes

Pessimistic (full nodes only)

A pessimistic rollup is a rollup that only supports full nodes that replay all the transactions in the rollup in order to check its validity. Rollkit supports pessimistic rollups by default.

Pessimistic rollups are similar to how Tether uses Bitcoin as a data availability layer via OmniLayer.

Optimistic (fraud proofs) (work in progress)

Rollkit's current design consists of a single sequencer that posts blocks to the DA layer, and multiple (optional) full nodes. Sequencers gossip block headers to full nodes and full nodes fetch posted blocks from the DA layer. Full nodes then execute transactions in these blocks to update their state, and gossip block headers over the P2P network to Rollkit light nodes.

Once state fraud proofs are enabled, when a block contains a fraudulent state transition, Rollkit full nodes can detect it by comparing intermediate state roots (ISRs) between transactions, and generate a state fraud proof that can be gossiped over the P2P network to Rollkit light nodes. These Rollkit light nodes can then use this state fraud proof to verify whether a fraudulent state transition occurred or not by themselves.

Overall, state fraud proofs will enable trust-minimization between full nodes and light nodes as long as there is at least one honest full node in the system that will generate state fraud proofs.

Note that Rollkit state fraud proofs are still a work in progress and will require new methods on top of ABCI, specifically, GenerateFraudProof, VerifyFraudProof, and GetAppHash.

You can find current detailed design and the remaining work needed to push state fraud proofs towards completion in this Architecture Decision Record (ADR).

Validity (ZK proofs)

Validity (ZK) rollups are planned, but not currently supported by Rollkit.

Released under the APACHE-2.0 License

- + \ No newline at end of file diff --git a/learn/transaction-flow.html b/learn/transaction-flow.html index 9256d9455..b4f1cba3c 100644 --- a/learn/transaction-flow.html +++ b/learn/transaction-flow.html @@ -60,7 +60,7 @@
On this page

Transaction flow

Rollup users use a light node to communicate with the rollup P2P network for two primary reasons:

  • submitting transactions
  • gossipping headers and fraud proofs

WARNING

Light nodes are still a work in progress.

Here's what the typical transaction flow looks like:

Transaction submission

null

Transaction validation and processing

null

Block processing

null

Fraud proof gossip and forking

null

To transact, users submit a transaction to their light node, which gossips the transaction to a full node. Before adding the transaction to their mempool, the full node checks its validity. Valid transactions are included in the mempool, while invalid ones are refused, and the user's transaction will not be processed.

If the transaction is valid and has been included in the mempool, the sequencer can add it to a rollup block, which is then submitted to the data availability (DA) layer. This results in a successful transaction flow for the user, and the state of the rollup is updated accordingly.

After the block is submitted to the DA layer, the full nodes download and validate the block. However, there is a possibility that the sequencer may maliciously submit a block to the DA layer with invalid transactions or state. In such cases, the full nodes of the rollup chain will consider the block invalid. In the case of an optimistic rollup, if they find the block invalid, they generate fraud proofs and gossip them in the P2P network among other full and light nodes.

As a result, the rollup chain will halt, and the network will decide to fork the chain through social consensus. In the future, when a decentralized sequencer scheme is in place, additional options will be available, such as slashing the sequencer or selecting another full node as the sequencer. However, in any case, a new block must be created and submitted to the DA layer. You can read more about sequencer nodes here.

Released under the APACHE-2.0 License

- + \ No newline at end of file diff --git a/testnets/cosmwasm-testnet.html b/testnets/cosmwasm-testnet.html index b2a112c94..0d5ddefe4 100644 --- a/testnets/cosmwasm-testnet.html +++ b/testnets/cosmwasm-testnet.html @@ -132,7 +132,7 @@ "sequence": "0" } }
  • Block Explorer: https://canary.modular.cloud/rollkit-cosmwasm
  • WARNING

    The modular.cloud explorer is work in progress. In the meanwhile, the wasm CLI can be used to query the accounts. For example: to collect the transactions for any account, following command can be used.

    wasmd query txs --query "message.sender='wasm1lysztpn74kl40w6ghfhy7xr0v44r658szuysl5'" --node https://rpc.rosm.rollkit.dev

    Add Rosm to Keplr

    Don't have the Keplr Browser extension? Add Keplr Wallet Here

    Click to add Rosm testnet to your Keplr wallet

    Released under the APACHE-2.0 License

    - + \ No newline at end of file diff --git a/tutorials/artela-evm-plus-plus.html b/tutorials/artela-evm-plus-plus.html index f2ad0d8af..341602868 100644 --- a/tutorials/artela-evm-plus-plus.html +++ b/tutorials/artela-evm-plus-plus.html @@ -68,7 +68,7 @@ ...

    🔑 Get prefunded test accounts

    Access testing accounts by entering the artroll Docker container:

    bash
    docker exec -ti artroll /bin/bash

    Retrieve the address and private key of testing accounts using:

    bash
    # 👇 Alternatively, you can use myKey2.info, myKey3.info, myKey4.info
     ./entrypoint keyinfo --file ~/.artroll/keyring-test/mykey.info --passwd test

    This will display the testing private key and its address:

    bash
    private key: { Plain Private Key in Hex Format }
     address: { Address Associated with the Private Key }

    There are four testing accounts available in the local development node for interacting with the EVM chain.

    🧪 Build on EVM++

    Let’s dive into Artela EVM++ by kicking off with the Hello World project, the following code will guide you through the essentials:

    👉 Contract interaction tutorial: Get hands-on experience with deploying and interacting with smart contracts on the Artela rollup node.

    TIP

    When you are following the Contract interaction tutorial, you need to make the following replacements:

    1. Use https://github.com/artela-network/gm-portal.git instead of the original gm-portal repo.
    2. Use the private key you obtained from the previous step in this tutorial instead of the one used in the Contract interaction tutorial.
    3. The contract address should be 0x9fcEbD70654D360b41ccD123dADAAad6ce13C788 instead of the one starts with 0x18D....

    👉 Quick Start for Aspect on EVM++: Try your first Aspect with Artela rollup node.

    TIP

    Please note that when you are following the Aspect on EVM++ tutorial, you need to make the following replacements:

    1. Replace npm install -g @artela/aspect-tool with npm install -g @artela-next/aspect-tool
    2. Replace the Artela Testnet node URL in project.config.json with http://localhost:8545 to connect to your local rollup node.
    3. Use the private key you obtained from the previous step in this tutorial instead of creating a new account.

    By now, we assume that you:

    • Have a basic understanding of Artela technology.
    • Have installed and played with Artela development tools.
    • Understand how Aspect functions and its impact on making dApps distinct and superior.
    • May already have numerous innovative ideas for building on Artela.

    📖 More to know

    If you want to gain a deeper understanding of Aspect’s capabilities and limitations to fully grasp how it can enhance or constrain your project, make sure not to overlook these essential concepts:

    💥 Build with examples

    Our community has built numbers of projects with Aspect, you can refer to these projects and modify them to learn how to use Aspect more effectively.

    Simple examples that use the basic functionalities of Aspect:

    Real-world use cases that show how to build more complex projects with Aspect:

    🛑 Stopping the Node

    To cease operations and shutdown the Artela rollup node, use:

    bash
    docker compose down

    This command halts all running containers and clears the environment.

    🎉 Conclusion

    Congratulations! You have successfully learnt some basic knowledge of EVM++ and have set up an Artela EVM++ rollup using Rollkit and local-DA. This setup enables you to test the integrated capabilities of Artela’s EVM++ with Rollkit.

    Released under the APACHE-2.0 License

    - + \ No newline at end of file diff --git a/tutorials/avail-da.html b/tutorials/avail-da.html index 1514d9d59..2a5c7a0ad 100644 --- a/tutorials/avail-da.html +++ b/tutorials/avail-da.html @@ -68,7 +68,7 @@ --rollkit.da_address="grpc://localhost:3000" \ --rollkit.da_start_height $DA_BLOCK_HEIGHT \ --minimum-gas-prices="0.1stake"

    Now, the rollup is running and posting blocks (aggregated in batches) to Avail. You can view your rollup by finding your account on Turing testnet

    INFO

    For details on configuring gas prices specifically for the DA network, see our DA Network Gas Price Guide. This is separate from the --minimum-gas-prices="0.025stake" setting, which is used for rollup network operations.

    🎉 Next steps

    Congratulations! You've built a local rollup that posts to Avail's testnets as well as locally. Well done! Now, go forth and build something great! Good luck!

    Released under the APACHE-2.0 License

    - + \ No newline at end of file diff --git a/tutorials/beaconkit.html b/tutorials/beaconkit.html index 6f1140afb..d536d915c 100644 --- a/tutorials/beaconkit.html +++ b/tutorials/beaconkit.html @@ -99,7 +99,7 @@ "0x20f33ce90a13a4b5e7697e3544c3083b8f8a51d4": { "balance": "0x123450000000000000000" },

    Conclusion

    Congratulations! You've successfully set up a BeaconKit node using Rollkit, creating your own sovereign rollup. This setup demonstrates the basic functionality of combining BeaconKit with Rollkit.

    Next Steps

    To further customize your rollup chain:

    1. Experiment with different Rollkit settings to optimize performance.
    2. Consider implementing custom smart contracts on your rollup.
    3. Test the scalability and performance of your rollup under various conditions.

    Troubleshooting

    If you encounter issues:

    • Ensure all prerequisites are correctly installed and up to date.
    • Check that your local DA node is running correctly on port 7980.
    • Verify that the Geth client is properly initialized and running.
    • Review the BeaconKit logs for any specific error messages.

    For more detailed information and updates, visit the BeaconKit GitHub repository and the Rollkit documentation.

    Released under the APACHE-2.0 License

    - + \ No newline at end of file diff --git a/tutorials/bitcoin.html b/tutorials/bitcoin.html index 69ccdb82c..0911640b8 100644 --- a/tutorials/bitcoin.html +++ b/tutorials/bitcoin.html @@ -181,7 +181,7 @@ --private-key $ANVIL_KEY --rpc-url $RPC_URL

    We can then perform read operations with cast call:

    bash
    cast call $CONTRACT_ADDRESS "getCount()(int)" --rpc-url $RPC_URL

    🧪 Deploying to the Ethermint sovereign rollup

    Now that we've deployed and tested locally, we can deploy to our Ethermint chain.

    First, we will need to export the private key generated by the ethermint init.sh script:

    bash
    PRIVATE_KEY=$(ethermintd keys unsafe-export-eth-key mykey --keyring-backend test)

    NOTE: Here, the key name from init.sh is mykey but you can modify the init.sh to change the name of your key.

    Now, we can start deploying the smart contract to our Ethermint chain.

    To do so, run the following script:

    bash
    forge script script/Counter.s.sol:CounterScript \
     --rpc-url http://127.0.0.1:8545 --private-key $PRIVATE_KEY --broadcast

    Set the contract address in the output as the CONTRACT_ADDRESS variable:

    bash
    export CONTRACT_ADDRESS=<new-contract-address>

    Once the contract has been deployed to the Ethermint rollup, we can use cast send to test sending transactions to it:

    bash
    cast send $CONTRACT_ADDRESS "incrementCounter()" \
     --rpc-url http://127.0.0.1:8545 --private-key $PRIVATE_KEY

    We can then perform read operations with cast call:

    bash
    cast call $CONTRACT_ADDRESS "getCount()(int)" --rpc-url http://127.0.0.1:8545

    Released under the APACHE-2.0 License

    - + \ No newline at end of file diff --git a/tutorials/celestia-da.html b/tutorials/celestia-da.html index 043d8a022..7b7ea83d0 100644 --- a/tutorials/celestia-da.html +++ b/tutorials/celestia-da.html @@ -73,7 +73,7 @@ --rollkit.da_start_height $DA_BLOCK_HEIGHT \ --rollkit.da_address $DA_ADDRESS \ --minimum-gas-prices="0.025stake"

    Now, the rollup is running and posting blocks (aggregated in batches) to Celestia. You can view your rollup by using your namespace or account on Mocha testnet or Mainnet Beta explorers.

    INFO

    For details on configuring gas prices, specifically for the Celestia network, see the DA Network Gas Price Guide. The Celestia gas price is separate from the --minimum-gas-prices="0.025stake" setting, which is used for the rollup network operations.

    🎉 Next steps

    Congratulations! You've built a local rollup that posts data to Celestia's DA layer. Well done! Now, go forth and build something great! Good luck!

    Released under the APACHE-2.0 License

    - + \ No newline at end of file diff --git a/tutorials/cosmwasm.html b/tutorials/cosmwasm.html index de0d1aca7..a66fa29da 100644 --- a/tutorials/cosmwasm.html +++ b/tutorials/cosmwasm.html @@ -160,7 +160,7 @@ tx: null txhash: C147257485B72E7FFA5FDB943C94CE951A37817554339586FFD645AD2AA397C3

    If you try to register the same name again, you'll see an expected error:

    bash
    Error: rpc error: code = Unknown desc = rpc error: code = Unknown desc = failed to execute message; message index: 0: Name has been taken (name fred): execute wasm contract failed [CosmWasm/wasmd/x/wasm/keeper/keeper.go:364] With gas wanted: '0' and gas used: '123809' : unknown request

    Next, query the owner of the name record:

    bash
    NAME_QUERY='{"resolve_record": {"name": "fred"}}'
     wasmd query wasm contract-state smart $CONTRACT "$NAME_QUERY" --node http://127.0.0.1:36657 --output json

    You'll see the owner's address in a JSON response:

    bash
    {"data":{"address":"wasm1y9ceqvnsnm9xtcdmhrjvv4rslgwfzmrzky2c5z"}}

    With that, we have instantiated and interacted with the CosmWasm nameservice smart contract on our local DA network using Rollkit!

    Released under the APACHE-2.0 License

    - + \ No newline at end of file diff --git a/tutorials/evm-contract-interaction.html b/tutorials/evm-contract-interaction.html index 366d966c9..6c631ec46 100644 --- a/tutorials/evm-contract-interaction.html +++ b/tutorials/evm-contract-interaction.html @@ -93,7 +93,7 @@ yarn && yarn dev

    Now, your frontend is running! We'll display and interact with our smart contract on our frontend.

    First, you will need to change the contract address on gm-portal/frontend/src/App.tsx to your contract address from above before you can interact with the contract on the frontend:

    TIP

    Only if you changed the contract, you will need to update the ABI in gm-portal/frontend/GmPortal.json from gm-portal/contracts/out/GmPortal.sol/GmPortal.json. This can be done with:

    bash
    cd $HOME
     cp gm-portal/contracts/out/GmPortal.sol/GmPortal.json gm-portal/frontend

    Interact with the frontend

    In order to interact with the contract on the frontend, you'll need to fund an account that you have in your Ethereum wallet or add the private key from above into your wallet.

    To transfer to an external account, use this command:

    bash
    export RECEIVER=<receiver ETH address>
     cast send --private-key $PRIVATE_KEY $RECEIVER --value 1ether --rpc-url $RPC_URL

    If you are in a different terminal than the one you set the private key in originally, you may need to set it again.

    Now, login with your wallet that you funded, and post a ooga booga on your ooga booga portal!

    frontend-evm

    Conclusion

    You have successfully deployed a smart contract to your EVM rollup and interacted with it on a frontend. You can now build more complex applications on your EVM rollup!

    Released under the APACHE-2.0 License

    - + \ No newline at end of file diff --git a/tutorials/gm-world-arabica-testnet.html b/tutorials/gm-world-arabica-testnet.html index 694c4d0bb..c6be48d67 100644 --- a/tutorials/gm-world-arabica-testnet.html +++ b/tutorials/gm-world-arabica-testnet.html @@ -94,7 +94,7 @@ _ = ctx return &types.QueryGmResponse{Text: "gm world!"}, nil }

    The query command has also scaffolded x/gm/client/cli/query_gm.go that implements a CLI equivalent of the gm query and mounted this command in x/gm/client/cli/query.go.

    Restart your rollup

    Restart your rollup by running the init-arabica-testnet.sh script again.

    Query your rollup

    In a separate window, run the following command:

    bash
    gmd q gm gm

    We will get the following JSON response:

    bash
    text: gm world!

    gm.png

    Next steps

    Congratulations 🎉 you've successfully built your first rollup and queried it!

    In the next tutorial, you'll learn how to post data to Celestia's Mainnet Beta.

    If you're interested in setting up a full node alongside your sequencer, see the Full and sequencer node rollup setup tutorial.

    Released under the APACHE-2.0 License

    - + \ No newline at end of file diff --git a/tutorials/gm-world-mainnet.html b/tutorials/gm-world-mainnet.html index 76cdcfeb9..d34b22171 100644 --- a/tutorials/gm-world-mainnet.html +++ b/tutorials/gm-world-mainnet.html @@ -62,7 +62,7 @@
    On this page

    GM world rollup: Part 3

    This tutorial is part 3 of the GM world rollup tutorials. In this tutorial, it is expected that you've completed part 1 or part 2 of the tutorial and are familiar with running a local rollup devnet or posting to a Celestia testnet.

    TIP

    This tutorial explores Rollkit, currently in Alpha. If you encounter bugs, please report them via a GitHub issue ticket or reach out in our Telegram group.

    Deploying to Celestia Mainnet Beta

    🪶 Run a Celestia light node

    Fully sync and fund a light node on Mainnet beta (celestia). Follow instructions to install and start your Celestia data availability layer light node selecting the Arabica network. You can find instructions to install and run the node. After the node is synced, stop the light node.

    Clear previous chain history

    Before starting the rollup, we need to remove the old project folders:

    bash
    rm -r $HOME/go/bin/gmd && rm -rf $HOME/.gm

    Start the rollup on mainnet

    For this portion, you will need to stop the rollup that you have running from parts 1 and 2 of the tutorial, using Control + C in the terminal.

    1. Download the script for deploying to Celestia's Mainnet Beta:

      bash
      # From inside the `gm` directory
       wget https://rollkit.dev/gm/init-mainnet.sh
    2. Ensure that the account for your light node is funded.

    3. Run the init-mainnet.sh script:

      bash
      bash init-mainnet.sh
    4. Watch as your rollup posts blocks to Celestia!

    5. View your rollup by finding your namespace or account Celenium.

    View the example rollup's namespace on Celenium.

    TIP

    init-mainnet.sh script uses a default namespace 00000000000000000000000000000000000000000008e5f679bf7116cb. You can set your own by using a command similar to this (or, you could get creative 😎):

    bash
    openssl rand -hex 10

    Replace the last 10 characters in 00000000000000000000000000000000000000000008e5f679bf7116cb with the newly generated 10 characters.

    Learn more about namespaces .

    Restarting your rollup

    When you ran init-mainnet.sh, the script generated a script called restart-mainnet.sh in the $HOME/gm directory for you to use to restart your rollup.

    In order to do so, restart celestia light node and then run:

    bash
    bash restart-mainnet.sh

    Next steps

    Congratulations! You have a Rollkit rollup running on Celestia's Mainnet Beta.

    If you're interested in setting up a full node alongside your sequencer, see the Full and sequencer node rollup setup tutorial.

    Released under the APACHE-2.0 License

    - + \ No newline at end of file diff --git a/tutorials/gm-world-mocha-testnet.html b/tutorials/gm-world-mocha-testnet.html index a388d0e17..56f619903 100644 --- a/tutorials/gm-world-mocha-testnet.html +++ b/tutorials/gm-world-mocha-testnet.html @@ -94,7 +94,7 @@ _ = ctx return &types.QueryGmResponse{Text: "gm world!"}, nil }

    The query command has also scaffolded x/gm/client/cli/query_gm.go that implements a CLI equivalent of the gm query and mounted this command in x/gm/client/cli/query.go.

    Restart your rollup

    Restart your rollup by running the init-mocha-testnet.sh script again.

    Query your rollup

    In a separate window, run the following command:

    bash
    gmd q gm gm

    We will get the following JSON response:

    bash
    text: gm world!

    gm.png

    Next steps

    Congratulations 🎉 you've successfully built your first rollup and queried it!

    In the next tutorial, you'll learn how to post data to Celestia's Mainnet Beta.

    If you're interested in setting up a full node alongside your sequencer, see the Full and sequencer node rollup setup tutorial.

    Released under the APACHE-2.0 License

    - + \ No newline at end of file diff --git a/tutorials/gm-world.html b/tutorials/gm-world.html index 674cd9062..769190a1a 100644 --- a/tutorials/gm-world.html +++ b/tutorials/gm-world.html @@ -180,7 +180,7 @@ pagination: next_key: null total: "0"

    📦 GM world UI app

    Now that you have an idea of how to interact with the rollup with the rollkit CLI, let's look at the user interface (UI) application aspect of connecting a wallet to a rollup.

    Connecting your wallet to your rollup is as straightforward as connecting to any other blockchain. It assumes you have the Keplr wallet extension installed in your browser.

    🔗 Connecting your wallet

    Kurtosis spun up a UI app alongside your rollup already, so to connect your Keplr wallet to the application, simply open your browser and go to http://localhost:3000.

    Click the "Connect Wallet" button on the page, and approve the connection request in the Keplr prompt.

    Once authorized, your wallet address will be displayed, confirming that your wallet is successfully connected.

    gm-world-frontend-connected

    TIP

    If you run into any issues, make sure your Keplr wallet is updated and set to connect to your local environment.

    🎉 Next steps

    Congratulations! You've experienced connecting to a rollup from the user side — simple and straightforward. Now, you might consider exploring how to add more application logic to your rollup using the Cosmos SDK, as demonstrated in our Wordle App tutorial.

    Released under the APACHE-2.0 License

    - + \ No newline at end of file diff --git a/tutorials/octane-evm.html b/tutorials/octane-evm.html index c51c6bb28..92a943b4c 100644 --- a/tutorials/octane-evm.html +++ b/tutorials/octane-evm.html @@ -62,7 +62,7 @@
    On this page

    Quick start guide for Omni Octane with Rollkit

    This guide will help you quickly set up and run an Omni node using Rollkit and local-DA.

    📦 Clone the Omni repository

    To get started, clone the Omni repository with the Rollkit branch:

    bash
    git clone -b rollkit https://github.com/rollkit/omni.git
     cd omni

    🏗️ Build Docker images

    Before running Omni, you need to build the Docker images. This step requires GoReleaser to be installed on your system. If you don't have GoReleaser, you'll need to install it first:

    • On macOS with Homebrew:
      bash
      brew install goreleaser
    • On Linux or Windows with Go installed:
      bash
      go install github.com/goreleaser/goreleaser@latest

    Make sure GoReleaser is in your PATH after installation.

    Once GoReleaser is installed, run the following command to build the Docker images:

    bash
    make build-docker

    This command will build all the necessary Docker images for running Omni with Rollkit.

    If you encounter any issues with GoReleaser or the build process, make sure you have sufficient free space on your machine. You can check your available disk space using the df -h command on Linux/macOS or powershell -command "Get-PSDrive -PSProvider 'FileSystem'" on Windows.

    🚀 Deploy Omni with Rollkit and local-DA

    To start your Omni node with Rollkit and local-DA, execute:

    bash
    make devnet-zero-deploy

    Upon execution, the command will set up and start your Omni node. You should see output indicating the progress and status of your node. Notice the EVM Chain RPC available message, which indicates that the Omni node is ready to accept EVM transactions:

    bash
    24-07-22 20:29:03.655 INFO EVM Chain RPC available                  chain_id=1651 chain_name=omni_evm url=http://127.0.0.1:8000

    🧪 Smart Contract Deployment and Interaction

    To deploy and interact with smart contracts on the Omni EVM, you can use the tools you are already familiar with, follow our Contract interaction tutorial to get a hands on experience.

    To fund your account with some tokens, you can use the omni-cli, which needs to be installed first:

    bash
    make install-cli # install omni cli 
     omni devnet fund --rpc-url http://127.0.0.1:8000 --address=<your address>

    🛑 Stopping the node

    When you're done and want to stop the Omni node, use the following command:

    bash
    make devnet-zero-clean

    This will stop all running containers and clean up the environment.

    🎉 Conclusion

    That's it! You've successfully set up and run an Omni node with Rollkit and local-DA. This setup allows you to experiment with Omni's capabilities integrated with Rollkit.

    Released under the APACHE-2.0 License

    - + \ No newline at end of file diff --git a/tutorials/polaris-evm.html b/tutorials/polaris-evm.html index 2da55f6ce..b7e1bc089 100644 --- a/tutorials/polaris-evm.html +++ b/tutorials/polaris-evm.html @@ -121,7 +121,7 @@ DA_BLOCK_HEIGHT=$(docker exec $(docker ps -q) celestia header local-head --token $AUTH_TOKEN | jq '.result.header.height' -r) DA_BLOCK_HEIGHT=$(curl https://rpc-mocha.pops.one/block |jq -r '.result.block.header.height')

    Start the EVM rollup

    Change into the Polaris directory in your terminal:

    bash
    cd $HOME/polaris
     make start

    Congratulations! Your light node is now posting your rollup's data to Celestia's Mocha testnet.

    Find an explorer to view the default namespace in the tutorial or search for your own namespace on Celenium.

    Released under the APACHE-2.0 License

    - + \ No newline at end of file diff --git a/tutorials/quick-start.html b/tutorials/quick-start.html index fb334b972..b59ff5983 100644 --- a/tutorials/quick-start.html +++ b/tutorials/quick-start.html @@ -67,7 +67,7 @@ I[2024-05-01|09:58:46.080] Started node module=main I[2024-05-01|09:58:46.081] Creating and publishing block module=BlockManager height=223 I[2024-05-01|09:58:46.082] Finalized block module=BlockManager height=223 num_txs_res=0 num_val_updates=0 block_app_hash=

    🎉 Conclusion

    That's it! Your sovereign rollup node is now up and running. It's incredibly simple to start a blockchain (which is essentially what a rollup is) these days using Rollkit. Explore further and discover how you can build useful applications on Rollkit. Good luck!

    Released under the APACHE-2.0 License

    - + \ No newline at end of file diff --git a/tutorials/wordle.html b/tutorials/wordle.html index 36ae97324..dce338e46 100644 --- a/tutorials/wordle.html +++ b/tutorials/wordle.html @@ -483,7 +483,7 @@ "total": "1" } }

    With that, we implemented a basic example of Wordle using Cosmos-SDK and Ignite and Rollkit.

    You can exit out of your docker container with:

    bash
    exit

    Then you can shut down your rollup and kurtosis by running:

    bash
    kurtosis clean -a

    Read on to how you can extend the code base.

    🔮 Extending in the future

    There are many ways this codebase can be extended:

    1. You can improve messaging around when you guess the correct word.
    2. You can hash the word prior to submitting it to the chain, ensuring the hashing is local so that it’s not revealed via front-running by others monitoring the plaintext string when it’s submitted on-chain.
    3. You can improve the UI in terminal using a nice interface for Wordle. Some examples are here.
    4. You can improve current date to stick to a specific timezone.
    5. You can create a bot that submits a wordle every day at a specific time.
    6. You can create a vue.js front-end with Ignite using example open-source repositories here and here.

    🎉 Next steps

    Congratulations! You've built a Wordle app using Cosmos-SDK and Rollkit. Now, explore connecting your rollup to DA networks like Celestia.

    Released under the APACHE-2.0 License

    - + \ No newline at end of file