PoC: running Op-Stack adapter

[rphmeier]

• Investigate API

[pepyakin]

The API of OP stack according to this.

// We will re-use some terminology from op-node codebase
// Ref is a reference to some object, so FrameRef is a reference to a frame
// DAChain allows reading and writing data to the DA layer

// FrameRef contains data to lookup a frame by its reference
// Here it contains the block height and the tx index at which the transaction
// was included, the combination of which uniquely references the frame.
type FrameRef struct {
    BlockHeight uint64
    TxIndex int64
}

// Marshal / Unmarshal
func (f *FrameRef) MarshalBinary(w io.Writer) error { ... }
func (f *FrameRef) UnmarshalBinary(r ByteReader) error { ... }

// FrameFetcher returns a Frame from the DAChain by it's FrameRef
type FrameFetcher interface {
    FetchFrame(ctx, ref FrameRef) ([]byte, error)
}

// FrameWriter writes a serialized Frame to the DAChain and returns its FrameRef
type FrameWriter interface {
    WriteFrame(ctx, []byte) (FrameRef, error)
}

// DAChain satisifes both read/write on the DAChain
type DAChain interface {
    FrameFetcher
    FrameWriter
}

and here is the actual impl of Celestia

[pepyakin]

You may ask, how are those frames created? I am not entirely sure, but it seems like the batches are created elsewhere and submitted on L1's special contract. This is what we discussed the other day, @rphmeier, where the order of batches is completely determined by L1 even though the data is stored somewhere else. Though it seems that the block height should be finalized block always. It would be ideal if L1 & DA are rooted in the same consensus. With celestia it's a bit worse.

In our case, it would be great³ to have OP deployed on Moonbeam. But I don't think it's for Sugondat Monocore Kusama