You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the DA architecture, we have three types of components:
DA client
DA server
Storage Backend
The storage process is as follows:
The DA server is the first to be started. When started, it reads the configuration file of multiple storage backends from the configuration. The configuration contains the URL and public key of each storage backend. The DA server then establishes connections to these storage backends and waits for DA client requests.
The DA client calls the Store interface and sends its data to the DA server. The DA server sends the data to multiple backends, checks if the signature returned by each backend is consistent, and verifies if the data hash returned by each backend is the same as computed by the DA client. Finally, the signatures and public keys of all successful backends are collected and aggregated into a multisignature, which is then verified for its legitimacy.
Finally, the DA server aggregates the results of multiple backends into a Data Availability Certificate (DAC) and returns it to the DA client.
The DA client can query the data related to the Data Availability Certificate (DAC) by using the GetByHash interface and specifying the data hash field.
For example, if we use the Celestia client as a backend for the DA server, we need to configure the private key of the Celestia Chain client and the namespace of the storage space before starting the DA server. When the DA server calls Celestia backend, it initiates a PayForBlob transaction to Celestia Chain, paying a certain amount of GasFee to store the Blob data on Celestia Chain. Celestia Chain returns transaction information, including transaction hash, which serves as the parameter for DA client to query data that has been stored.
The text was updated successfully, but these errors were encountered:
In the DA architecture, we have three types of components:
The storage process is as follows:
The DA server is the first to be started. When started, it reads the configuration file of multiple storage backends from the configuration. The configuration contains the URL and public key of each storage backend. The DA server then establishes connections to these storage backends and waits for DA client requests.
The DA client calls the
Store
interface and sends its data to the DA server. The DA server sends the data to multiple backends, checks if the signature returned by each backend is consistent, and verifies if the data hash returned by each backend is the same as computed by the DA client. Finally, the signatures and public keys of all successful backends are collected and aggregated into a multisignature, which is then verified for its legitimacy.Finally, the DA server aggregates the results of multiple backends into a
Data Availability Certificate (DAC)
and returns it to the DA client.The DA client can query the data related to the
Data Availability Certificate (DAC)
by using theGetByHash
interface and specifying the data hash field.For example, if we use the Celestia client as a backend for the DA server, we need to configure the private key of the Celestia Chain client and the namespace of the storage space before starting the DA server. When the DA server calls Celestia backend, it initiates a PayForBlob transaction to Celestia Chain, paying a certain amount of GasFee to store the Blob data on Celestia Chain. Celestia Chain returns transaction information, including transaction hash, which serves as the parameter for DA client to query data that has been stored.
The text was updated successfully, but these errors were encountered: