Thread - Nostr Hypermedia

I think my previous posts in this thread outline a safe solution to the data availability problem. By protocol, a sequencer merkelizes every sidechain block and posts the root on bitcoin via a piggyback mechanism. If he is a good sequencer, he also broadcasts the full block data on a secondary platform, such as his website. Users use that data to create transactions that update their state. If the sequencer ever withholds data, any user can start a challenge that forces the sequencer, at risk of getting slashed, to reveal a portion of the latest blockchain data. Specifically, the sequencer must reveal the portion involving that user's latest state, and then, whatever that state indicates about the user's balance, the sequencer must pay it out to the user on L1, if the user agrees that it is the right state. If the user claims the state has the wrong amount, the user can issue another challenge in which they present their "real" latest state and challenge the sequencer to prove a valid state transition which reduced the user's balance with their approval. The sequencer cannot do this if the user is honest, so they get slashed; or, if the user is dishonest, the challenge ends with no bad consequences for the sequencer. To disincentivize users from constantly issuing troll challenges, users must pay the cost of putting all challenge data on chain. If the sequencer does not post valid data, the sequencer gets slashed, and the user exits possibly even richer than he was before. If the sequencer posts valid data, the user has now exited and the data withholding attack was repeled by forcing the sequencer to reveal it or get slashed. The user paid extra for this "unilateral exit," but it is common for unilateral exits to cost more than cooperative ones, so that is fine imo. If the sequencer is unreliable about revealing valid data, he will lose his customers with no gain, and if he is reliable, none of this happens in the first place, because no one has an incentive to issue a costly challenge if the sequencer is doing everything right. For more details, I have a writeup here:

Telegraph

A forthcoming problem with bitvm

Introduction In the past few months, several bitvm companies announced preparations for launching on mainnet, and I began to research their plans. ...

↑ Parent

Replies (4)

Nuh 3 weeks ago

I think you are not noticing what I am saying; whoever slashes the sequencer could have been themselves the Data Availability Committee and sign on all blocks... Unless you mean slashing with BitVM which means the data has to be posted with BitVM hacks... In which case I check out. Either way, it is not clear why should we bother with introducing a challenge system for DA, when we already have a proof of publication, and we would be using it not to post dick butts but to basically add something that everyone agrees is needed. Is it really better to post tons of inflated data with BitVM challenges, than just write contracts onchain and hold the escrows accountable that way. I didn't even mention the effect of watching the demand for smart contracts evident on chain. Anyways, I think I understand your position now, thanks.

1 replies ↓

Nuh 3 weeks ago

I think your main issue with using L1 for DA, is that you think people are trying to add scalability... No, people are trying to have usuable smart contracts, then do all the fraud proofs or validity proofs or proof of stake and any tricks they might need for scaling there, with actual smart contract language that is not as awful as BitVM (which by the way forces people to use ZKVMs that are far from water tight)... So it doesn't matter that the "side"'chain will be expensive, it is not meant to compete with LN it is meant to make L2s nicer to develop+ enable things like Stablecoins and vaults ... All usecases for large transactions anyways.

Super Testnet 3 weeks ago

> Is it really better to post tons of inflated data with BitVM challenges, than just write contracts onchain and hold the escrows accountable that way Using bitvm doesn't require posting tons of data anymore. Ever since the realization that bitvm can use garbled circuits, two benefits emerged: (1) you only need to post data in the sad path and (2) the data only needs to be one or two standard preimages and hashes -- nearly the same amount of data required to resolve a lightning htlc on L1. That is far better than writing every smart contract on chain. It is cheaper for end users and less spammy for nodes.

1 replies ↓

Super Testnet 3 weeks ago

> you think people are trying to add scalability... No, people are trying to have usuable smart contracts I thunk they are trying to do both, and I think my proposal is the cheapest way to do both proposed so far, and as a result, also the least spammy. > [they want an] actual smart contract language that is not as awful as BitVM Bitvm allows you to use any smart contract lamguage you want. Normal devs are not expected to write their programs in binary circuits, that's what compilers are for. > [bitvm] forces people to use ZKVMs that are far from water tight I am unfamiliar with this criticism, do you have more details or a link to where I can read more?

1 replies ↓