Centralized Blob Signer Validation

[l-monninger]

Summary

While the centralized launch of the network does not require us to validate blob publishers are staked, as in MD-6, it is still advisable to validate that the centralized node(s) indeed published a blob to Celestia to prevent against DOS attacks.

Because other nodes who do not publish will also need to verify these blobs, the most conventional solution is simply to use an owned keypair to sign all blobs and share the public key with the community.

Signed Blob

Format

Celestia does not appear to have well-documented API support for checking who submitted a given blob. Presumably, this is possible via the transaction API, however, it is unclear how to query for a transaction matching a certain blob. Thus, for simplicity, the transaction itself can be signed. Signed blobs can take the following form.

SignedBlob = (Data, Signature)

Where to Sign

Within the context of the current m1-da-light-node, we may take one of two approaches to conducting this signing:

1. Move the signing up in the stack s.t. user of the m1-da-light-node expect signed blocks to be returned.
2. Keep the m1-da-light-node message types as is, encapsulating signature verification from the application level.

I would suggest Option 1, as it gives both us and others more flexibility down the road.

How to Sign

Because we are working towards a presumed requirement that blob publishers be staked, I believe it is simplest to reuse the the ETH_SIGNING_KEY and thus sign under the secp256k1 standard.

In the future, we will want to discuss more completely how this affects node operator user journeys. Currently, the presence or absence of this value will also turn on or off the settlement loop. However, we would likely want to control this under a separate variable going forward as users--based on proposed reward models--can rationally choose to be staked and to publish blobs without settling.

[mzabaluev]

Looks sensible. I don't have a preference on whether the signature format is app-specific vs. native in M1 DA.

On technical details:

SignedBlob = (Data, Signature)

In the signed blob format, Data is presumably the current compressed uncompressed blob format. We further add a BCS envelope with the signature. Compression, if any, is applied on top.

it is simplest to reuse the the ETH_SIGNING_KEY and thus sign under the secp256k1 standard.

OK. If we need to evolve this in the future, the changes will be managed under MIP-13

[l-monninger]

OK. If we need to evolve this in the future, the changes will be managed under movementlabsxyz/MIP#13

Do you see a way around this for centralized mainnet?

[mzabaluev]

Do you see a way around this for centralized mainnet?

Sure, coordinated upgrades don't need the migration config. If the pre-upgrade blobs are not accessed by the services during operation, we don't even need to hardcode upgrade heights.

[mzabaluev]

Currently, we are compressing in the sequencer and decompressing in the full-node. This was done for ease of implementation. I would propose moving all of the compression logic down into the sequencer.

I agree. So the current m1-da-light-node protocol de-facto applies compression asymmetrically? There are some benefits to the wire traffic, but this should be made moot by HTTP compression on the gRPC connection.

As such, Data would be the uncompressed blob format and both the blob and signature would be compressed and decompressed.

OK. Just to nitpick, the signature is a blob of random data from the point of view of stream compression protocols. But the tuple framing has low entropy, so there will be some marginal gain in compressing it.

[l-monninger]

I agree. So the current m1-da-light-node protocol de-facto applies compression asymmetrically? There are some benefits to the wire traffic, but this should be made moot by HTTP compression on the gRPC connection.

Agreed.

[l-monninger]

OK. Just to nitpick, the signature is a blob of random data from the point of view of stream compression protocols. But the tuple framing has low entropy, so there will be some marginal gain in compressing it.

Yeah, I was mainly just thinking it'll just be cleaner in implementation to compress the whole tuple.