#rollups

‍

Marigold and TriliTech are pleased to announce the successful deployment of a fully working Data Availability Committees on the Ghostnet Tezos network.

To learn more about Data Availability Committees, Nomadic Labs published an excellent article explaining everything in detail.

‍

⚠️ Disclaimer

Please note that this Community DAC is run on best-effort. We do not provide a guarantee on uptime or data lifetime storage. Hence, it should be only used for testing purposes.

Moreover, DAC is an experimental executable available since Octez v18.0. Hence, feedback is welcome!

⚠️ End of disclaimer

‍

TL;DR: What is a DAC?

The introduction of the Nomadic Labs/TriliTech article is the best one you can find; let’s reproduce it here:

A Data Availability Committee (DAC) is a solution for scaling the transaction throughput of Tezos Smart Rollups. In summary, a DAC enables storing transaction data for a smart rollup off-chain. Rollup nodes retrieve the transaction payloads from the DAC members and import them into their Smart Rollup virtual machines, instead of retrieving them directly from Tezos blocks, and thus circumvent the data limit imposed by Tezos block sizes.

‍

Community DAC.

Eager to scale the transaction throughput of Tezos Smart Rollups, Marigold and Trili Tech have decided to run their shared DAC.

Here is the complete infrastructure deployed so far:

1 Coordinator (managed by Marigold)
3 Members (2 managed by Marigold and 1 by TriliTech)
2 Observers (1 managed by Marigold and 1 by TriliTech)

‍

Play with Community DAC.

In this quick tutorial, we are going to give you the commands to:

Push data to Community DAC
Retrieve certificate
Retrieve data

‍

Send the payload.

The first step is, of course, to post your data on the Community DAC.

DAC has been included in the Tezos Shell CLI since v18.0, you can use the octez-dac-client binary to interact with it.

I want to post the string Marigold and Trili Tech run Community DAC! as an example.

1. Get the hexadecimal representation (you can use whatever tool you want, there are many online), which is 4D617269676F6C6420616E64205472696C6920546563682072756E20436F6D6D756E6974792044414321

2. Push the data

‍

Using CLI.


$ octez-dac-client send payload to coordinator https://dac-ghost-coordinator.gcp.marigold.dev/ with content "4D617269676F6C6420616E64205472696C6920546563682072756E20436F6D6D756E6974792044414321"

Which must return the root_hash! of the stored data:


Payload stored under root hash: 00e841b90074cdd84154c0fc2e841a15a70a08c45840fc0ca8211463aaf30bc29d

‍

Using curl.

It is also possible to push data using curl, which could be convenient for Smart Rollups with a frontend. Simply call the POST /preimage, endpoint, providing the hexadecimal representation of your data.


$ curl \
--location 'https://dac-ghost-coordinator.gcp.marigold.dev/v0/preimage' \
--header 'Content-Type: application/json' \
--data '"4D617269676F6C6420616E64205472696C6920546563682072756E20436F6D6D756E6974792044414321"'

Since we have already pushed the exact same data with the CLI, this curl will return the exact same root_hash.

🎉 Data is available on Community DAC! Let’s get its certificate!

‍

Retrieve the corresponding certificate.

DAC provides a certificate to ensure sure your data is well-signed and stored. It will be useful for Smart rollups to reveal the data.

‍

Using CLI.

As explained in the documentation, to retrieve the certificate of our previously pushed data, simply run the get certificate command, with the returned root hash:


$ octez-dac-client get certificate from coordinator https://dac-ghost-coordinator.gcp.marigold.dev for root hash '00e841b90074cdd84154c0fc2e841a15a70a08c45840fc0ca8211463aaf30bc29d'

This command will return you the hexadecimal representation of the serialized certificate compatible with Kernel SDK (we will see that in a following blog post).

‍

Using curl.

Actually, there are two different endpoints to get certificate because there are two different types of certificate.

/serialized_certificates which returns the exact same certificate than the previous command

/certificates which is basically the JSON representation of the exact same certificate.


$ curl --location 'https://dac-ghost-coordinator.gcp.marigold.dev/v0/certificates/00e841b90074cdd84154c0fc2e841a15a70a08c45840fc0ca8211463aaf30bc29d'

This curl will return the following JSON:


{
  "version": 0,
  "root_hash": "00e841b90074cdd84154c0fc2e841a15a70a08c45840fc0ca8211463aaf30bc29d",
  "aggregate_signature": "asigFjVKtS9owKaPZ9qhs5SFFRDn66kc1NY1y23nF4NbTU64gxNB78oPnFXbFf7FsJyocbsawPUoPadZKqYKUwX8hshpgHXTnjCNsYVxs19NtqRPeftSevkSNbPQ3SKVFX6E6FMfAcFKy",
  "witnesses": "1"
}

‍

Retrieve the data to finish the loop.

This step is a bonus one. In real life, the data will be revealed by Kernel SDK on your Smart Rollup side. Hence, there is no way to retrieve it via CLI.

But, for convenience, we expose a GET /preimage endpoint, which can be called:


$ curl --location 'https://dac-ghost-coordinator.gcp.marigold.dev/v0/preimage/00e841b90074cdd84154c0fc2e841a15a70a08c45840fc0ca8211463aaf30bc29d'

And will return your data as a sequence of bytes:


"000000002a4d617269676f6c6420616e64205472696c6920546563682072756e20436f6d6d756e6974792044414321"

‍

You will not retrieve the same data that was posted, mostly because of the pages encoding which add 5 prefix bytes (see the 000000002a prefix), and because in general if the data is greater than 4091 bytes, the root hash page will contain the hashes of other pages.

Voilà!

You have successfully:

pushed data to Community DAC,
retrieved corresponding certificate
obtained back the data

In a following blog post, we will see how to deploy your own DAC infrastructure for your Smart Rollups!

‍

Going further.

In this blog post we have seen how to interact with the Ghostnet Community DAC using CLI and curl. But how about using it in your Smart Rollups?

Having a more global Smart Rollups example using DAC is the subject of a next blog post coming soon, but since we ask for feedback, here are the Public Keys and Public Key Hashes you need to use this Community DAC inside your Smart Rollups:


MARIGOLD_MEMBER1_PKH=tz4EXupF2QRtHyrHW7Cy7y1jtW48NhgcZvXP
MARIGOLD_MEMBER1_PK=BLpk1nEyxfm3tzJ6Xx6S2UVgMonQ3KFBjKWEZ2TgJg89S7Mykb5dPsT8w7zeg1iUAVXgUqZqybX7
MARIGOLD_MEMBER2_PKH=tz4RnqbpM3PiFGWgAAr2xZGAQKeRM5nqYppq
MARIGOLD_MEMBER2_PK=BLpk1nHoWTSPMiG1W8qpimTSqrosAxc1L33Hyb9xHgXeVSZkzg26BxMunwajX2zekW8KuuT8Y4LP
TRILITECH_MEMBER_PKH=tz4CdFt1ktHZz3mfLtmt8e1YwbSvioL7aQEs
TRILITECH_MEMBER_PK=BLpk1vDSzZnZK8A5URoRTgNoC22GeAVRwFBdZPoxN9upzfMqwonXdqubAxYq4GaJTSMW6ECnPwNJ

‍

Please note you need to run your own DAC Observer, sharing reveal_data_dir with your Smart Rollups, to use DAC. You can configure and start your own Community DAC Observer by running the following commands:


octez-dac-node configure as observer with coordinator https://dac-ghost-coordinator.gcp.marigold.dev and committee member rpc addresses https://dac-ghost-member1.gcp.marigold.dev https://dac-ghost-member2.gcp.marigold.dev 34.111.118.121 --data-dir ${OBSERVER_DIR} --reveal-data-dir ${REVEAL_DATA_DIR}
//The IP is the TriliTech member, waiting for its domain!

octez-dac-node -d ${OCTEZ_CLIENT_DIR} -E ${GHOSTNET_RPC} run --data-dir ${OBSERVER_DIR}

Have fun!

‍

If you want to know more about Marigold, please follow us on social media (Twitter, Reddit, Linkedin)!