Round-based Abraxas with centralized coordinator

[adambor]

By switching Abraxas to be round-based & introducing a centralized coordinator we can completely eliminate the DA issues (with ephemeral data), clients would participate in the signing round (akin to coinjoin rounds) producing aggregate signatures on the merkle root of the full transaction data and would only finish the signing session if they got a proper merkle proof for their transaction (removing the need for DA).

Round steps:

1. Users submits transactions to be confirmed in the current round + their signature nonce & sign the request by their key (to prove they have the private key)
2. Coordinator aggregates the transactions into a merkle tree + aggregates signature nonces & public keys from the users
3. Coordinator sends aggregate signature nonce + merkle proof to users
4. User verifies merkle proof for his transaction, and creates partial signature with his private key
5. Coordinator aggregates all the partial signature to compute a single aggregate signature
6. Coordinator computes a succinct proof proving validity of all the transactions (without the signature verification, as that is already verified by the aggregate signature)
7. Coordinator publishes the data on-chain as an inscription (txs merkle root + aggregate public key + aggregate signature + succinct STARK proof)

This requires just 2 rounds of communication between users & coordinator.

Anyone can verify the inscription published on-chain (by verifying the signature & STARK proof) and this is validated by the Abraxas nodes.

At first glance this looks pretty centralized (having a single coordinator in the middle), but the beauty of this system is that users are not bound to a single coordinator (their single-use-seals are not bound to a specific coordinator) & in the worst case can transact themselves by publishing a transaction on-chain (self-sequence as it'd be called in the Ethereum rollup world), this is similar to LNP/BP's SSIs, which can be revoked ("seal closed") by anyone including specific data in their transaction. Furthermore, as this operates with a purely client-side-validated system (like RGB), coordinators are completely blind as to what is actually happening in the transactions they are processing (they can only see the public keys & closed seal ids).

The end goal should be (hopefully) tens or maybe hundred separate coordinators - as long as there is a single coordinator not censoring a specific user, that user is able to transact cheaply, and in case every coordinator censors him he can still self-sequence in an on-chain bitcoin transaction.

This system might also be able to achieve cryptoeconomically secure sub bitcoin blocktime (<10 minutes) confirmation times by letting the coordinator post a bond in BTC that is slashable in case the coordinator double-spends an on-chain transaction. This however seems to be only possible with CSFS (checksigfromstack) or OP_CAT and is a matter of further research whether this can be implemented on bitcoin today.