data availability design

[lispc]

The meaning of 'data availability' is to enable proving account has balance of token in the tree. So order details are not needed.

SpotTrade:

AccountID1 4bytes
AccountID2 4bytes
tokenID_1to2 2bytes
tokenID_2to1 2bytes
Amount1to2 3bytes
Amount2to1 3bytes
// NewAccount1OrderRoot 
// NewAccount2OrderRoot
// although hash root is only 1 field element, it consumes many bytes in fact. So we prefer use original data
Order1Pos 2bytes
Order1ID 4bytes
Order1BuyAmount 3bytes
Order1SellAmount 3bytes
// Order1SellFilled 
// Order1BuyFilled
.. and for order2 ..

So total 42 bytes.

DepositToOld:

AccountID1 4bytes
tokenID1 2bytes
Amount1 3bytes

DepositToNew

AccountID1 4bytes
tokenID1 2bytes
Amount1 3bytes
ethAddr: 20bytes
sign 1bit
ay field: 32 bytes

total: 61bytes

Transfer

AccountID1 4bytes
AccountID2 4bytes
tokenID2bytes
Amount 3bytes

Withdraw

AccountID1 4bytes
tokenID1 2bytes
Amount1 3bytes

[lispc]

we may use poseidon / fields rather than sha3/bits first. This will make development/test easier. Once the design is finalized, we can switch to sha3/bits_encoding.

[lispc]

we can handle L1(withdraw&deposit) tx data and L2(trading&transfer) tx data differently. eg, only put L1 tx data onchain, or limit L1 tx num in each l2 block

[lispc]

(only transfer now)

Step1 without amount encoding. circuits add 1 public input block: hash(data)

Step2 (optional) with amount encoding

step 3: check availalibity: check reconstructing data can get correct merkle root (rust)

more: well-designed integer encoding / a DA tree + a non-DA tree / spottrade and other txs

[noel2004]

As reference, in hermez they has hashed:

• chainID

• batch number

• For each tx: from / to / amount / tokenID / nonce / fee:

  • All fields input has been compressed, and decoded to bits inside circuit, except for amount
  • they use nLevel bits (nLevel is the depth of Merkle tree) for account ID so they do need to take 32bits

[noel2004]

Compare to our current circuit:

1. We do not encode (compress) tx before input, so we just need to turn the required field into bits and hash them. It would save some cost in proof.

And we can still post the compressed data (raw data being hashed) in rollup tx?

2. For different type of tx, variant length for (encoded) tx being used in hasher would be essential, padding to longest tx (spot) should be unacceptable. （not work, the length of encoding bits must fixed)