DA Layer Byte Coordination

[trianglesphere]

This discussion is for different DA layers to coordinate their DA Layer version bytes to ensure that different DA layers do not share the same byte.

[teddyknox]

EigenDA will take da_layer_byte 0.

[rac-sri]

Avail will take da_layer_byte 0x0a

[emilianobonassi]

Conduit will take da_layer_byte 0x01

[tuxcanfly]

Celestia will take da_layer_byte 0x0c

[dndll]

NEAR will take da_layer_byte 0x6e

[csdtowards]

0g DA will take da_layer_byte 0x47

[K-Ho]

Will take da_layer_byte 0xff (changed from 0x02) for keccak commitments, for use with centralized DA like Amazon S3 or GCS.

[K-Ho]

updated. Thanks we'll use 0xff for the DA Layer byte for keccak commitments

[koushiro]

IMO, the DA Layer byte is only used by GenericCommitmentType (type 1, see https://specs.optimism.io/experimental/alt-da.html#input-commitment-submission), I am so confused, what's the DA Layer byte for keccak commitment (type 0).

BTW, in the op spec

The DA layer byte must be initially restricted to the range [0, 127).

[koushiro]

The da_layer_byte here tends to express the generic commitment payload protocol of a certain "da server" (the encoding rules of the payload or the key, rather than where the data is stored. Of course, it can also be narrowly understood that the different payload encoding rules imply the differences of the 'da server', which is the difference in the storage destination).

You can only say that the default implementation of the op da server uses 0xff to express its generic commitment payload protocol, which means the actual payload (the returned key) is a random number within a range, but it can't express the actual storage destination (local file or s3, both of them are supported by the default implementation of op-plasm da server).

op-plasm da server (provided by optimism):

func (d *DAServer) HandlePut(w http.ResponseWriter, r *http.Request) {
	d.log.Info("PUT", "url", r.URL)

	route := path.Dir(r.URL.Path)
	if route != "/put" {
		w.WriteHeader(http.StatusBadRequest)
		return
	}

	input, err := io.ReadAll(r.Body)
	if err != nil {
		d.log.Error("Failed to read request body", "err", err)
		w.WriteHeader(http.StatusBadRequest)
		return
	}

	if r.URL.Path == "/put" || r.URL.Path == "/put/" { // without commitment
		var comm []byte
		if d.useGenericComm {
			n, err := rand.Int(rand.Reader, big.NewInt(99999999999999))
			if err != nil {
				d.log.Error("Failed to generate commitment", "err", err)
				w.WriteHeader(http.StatusInternalServerError)
				return
			}
			comm = append(comm, 0x01)
			comm = append(comm, 0xff)    // <================ da_layer_byte: 0xff, maybe you guys talking about this?
			comm = append(comm, n.Bytes()...)

		} else {
			comm = NewKeccak256Commitment(input).Encode()
		}

		if err = d.store.Put(r.Context(), comm, input); err != nil {
			d.log.Error("Failed to store commitment to the DA server", "err", err, "comm", comm)
			w.WriteHeader(http.StatusInternalServerError)
			return
		}
		d.log.Info("stored commitment", "key", hex.EncodeToString(comm), "input_len", len(input))

		if _, err := w.Write(comm); err != nil {
			d.log.Error("Failed to write commitment request body", "err", err, "comm", comm)
			w.WriteHeader(http.StatusInternalServerError)
			return
		}
	} else {
		key := path.Base(r.URL.Path)
		comm, err := hexutil.Decode(key)
		if err != nil {
			d.log.Error("Failed to decode commitment", "err", err, "key", key)
			w.WriteHeader(http.StatusBadRequest)
			return
		}

		if err := d.store.Put(r.Context(), comm, input); err != nil {
			d.log.Error("Failed to store commitment to the DA server", "err", err, "key", key)
			w.WriteHeader(http.StatusInternalServerError)
			return
		}
		w.WriteHeader(http.StatusOK)
	}
}

[atenjin]

By the way, in your spec, the scope is [0, 127) (https://specs.optimism.io/experimental/alt-da.html?highlight=127#input-commitment-submission), which means the 0xff does not in this scope.
Do you still want to use this byte?
@sebastianst @K-Ho

[vdrg]

@K-Ho If we want to have multiple keccak256 commitments in the same batch transaction, would it make sense to reuse this same DA Layer byte? The tx calldata could be encoded as follows:

<DerivationVersion1> + <GenericCommitmentType> + 0xff + Keccak256(<DerivationVersion0> + Frame0) + Keccak256(<DerivationVersion0> + Frame1) + ...

[shahrizalzz]

ZETRIX will take da_layer_byte 0x7a