vrypan |--o--| on Warpcast

Content pfp

0 reply

20 recasts

20 reactions

Varun Srinivasan pfp

Varun Srinivasan

@vrypan raises an important point about the tradeoffs of snapchains design. If we only have 10 nodes that can validate messages isn’t that bad for decentralization? Let’s start with the problem that Snapchain is solving. Our deltagraph network lets any hub add a new message at any time. As the network grows, failures between nodes increase and delays become inevitable. You have to be able to “check” your sync state with a large percentage of the network in a short amount of time and this breaks down quickly. When it does, users will complain about messages moving very slowly between apps, which will make them less likely to use Farcaster, and less likely for apps to be built.

5 replies

29 recasts

184 reactions

Varun Srinivasan pfp

Varun Srinivasan

1 reply

0 recast

1 reaction

shazow pfp

Have you considered doing something like an L3 and leveraging existing consensus rather than building your own? For example, nodes could race to commit a merkle root of messages for the next epoch, let the rollup consensus decide who wins.

2 replies

0 recast

0 reaction

Varun Srinivasan pfp

Varun Srinivasan

Most of the complexity of consensus lies in getting agreement on who gets to commit the merkle root and whether messages are valid

1 reply

0 recast

1 reaction

vrypan |--o--| pfp

@shazow.eth you may want to take a look at https://gist.github.com/vrypan/1ae6a60ecb3741ab031b5b06c974acab I'm trying to identify its week spots, and fix them if possible, so that it can be considered an alternative to snapchain.

1 reply

0 recast

1 reaction

shazow pfp

I did read through it when you first shared it too! Just took another look, some thoughts: 1. Agreed that bond to join writing-hubs set makes sense (but I'm generally pro-bonds, even if it's not money and even if it's not slashable). 2. Agreed that a kind of "mempool" is necessary. 3. I like that this can be implemented as a smart contract, e.g. on a rollup (rather than a standalone L1) 4. I worry about spamming OCEC as a DoS, especially if this is used as a metric for winning the next block. Could be a censorship attack vector. But we can imagine other metrics for scoring, for example: a. Block that contains *oldest* message that hasn't been included yet b. Randomness is always good for thwarting attacks that rely on consecutive blocks, but need to avoid devolving into PoW. Maybe use RANDAO value to influence selection onchain.

1 reply

0 recast

0 reaction

vrypan |--o--| pfp

OCEC can't be spammed. It's the number of onchain events, and it is defined by the OP chain where our contracts are deployed. What am I missing? If you can construct an attack scenario, it would help a lot! Messages do not have age, and the timestamp can be set arbitrarily. This is ok in case of adding/removing reactions, where the user is free to decide what comes first, but it's not reliable.

1 reply

0 recast

0 reaction

shazow pfp

I assume message datastructure contents are enclosed in a signature from the sending account, right? Are there any heuristics for what is the oldest allowed message before it's invalid? Or can I craft a 0001-01-01 message today and it'll just be accepted? Re attack scenario: Couldn't a hub operator have a few accounts that do actions that generates a lot of OnChainEvents just to pad their own blocks and consistently exceed competing honest blocks?

1 reply

0 recast

0 reaction

vrypan |--o--| pfp

You can use any timestamp after the "farcaster era" (don't remember the date exactly) and no later than now+10 minutes (or something like this). Attack: Yes, you can create as many unchain events as you want, but everyone will also receive them at the same time. And then you will have to compete with Warpcast that may have more deltas to add to the block.

1 reply

0 recast

1 reaction

shazow pfp

Wouldn't you know of them before everyone else receives them at the same time? You can prepare the event transactions ahead of time, prepare your block ahead of time with the events that aren't sequenced yet, then submit them all at the ~same time.

1 reply

0 recast

0 reaction

vrypan |--o--| pfp

Hmm.. Maybe. But submitting the tx does not mean it will be processed. I have updated the design and miners have to wait for 5 OP blocks to create a new farcaster block. If what you describe is possible, then we can set a limitation that onchain events must be older than the last OP block, even older than -2 blocks.

2 replies

0 recast

0 reaction

vrypan |--o--| pfp

This is the current OnChainEvent format. So, we can also enforce a rule that requires events to be up to a specific block height, leaving time for everyone to process them.

1 reply

0 recast

1 reaction