Samuel pfp
Samuel
@samuellhuber.eth
Snapchain read together. Let's go through it live. I haven't read the current iteration, excited to see https://events.xyz/events/87fbe2
1 reply
0 recast
3 reactions

Samuel pfp
Samuel
@samuellhuber.eth
figuring out why I am not live, sec.
1 reply
0 recast
0 reaction

Samuel pfp
Samuel
@samuellhuber.eth
LIVE https://youtube.com/live/O2niSA8aRvQ
1 reply
0 recast
0 reaction

Samuel pfp
Samuel
@samuellhuber.eth
"Snapchain is a replacement for Farcaster’s deltagraph that solves this problem. It uses the blockchain pattern to introduce ordering and achieve real-time delivery" @cassie calls this a Timechain see https://youtu.be/9P3eTJl9ZlY
1 reply
0 recast
0 reaction

Samuel pfp
Samuel
@samuellhuber.eth
I see "app keys" mention a lot in the Snapchain proposal once snapchain launches can we then rebrand it everywhere from signer to app key? like also in the spec and docs everywhere?
1 reply
0 recast
0 reaction

Samuel pfp
Samuel
@samuellhuber.eth
"A user’s account state is a set of blockchain and snapchain transactions. A new transaction either adds itself to the account state or replaces or deletes a prior transaction. " THis also means less state growth as we the deletion of overwritten messages (e.g. unlike -> remove the like in the first place) ensures minimal use of storage
1 reply
0 recast
0 reaction

Samuel pfp
Samuel
@samuellhuber.eth
"Transactions are broadcast into a mempool and then sequenced into blocks. A block contains blockchain and snapchain transactions along with a link to the previous block, a signature from the block producer and the global state root. The root is computed by creating a global state trie whose leaves are the state roots of each account. " The above clearly sounds like eventually to prove honesty and keep each snap producer honest there will be stakes/slashing or some other mechanism but since each producer is uniquely identified it can work just like Ethereum, Bitcoin and other blockchains do it. So the path to decentralization looks like figuring that system out and getting there
1 reply
0 recast
0 reaction

Samuel pfp
Samuel
@samuellhuber.eth
now replace Mainchain with Snapchain and you have a visualisation for how sharding and who validates what in Snapchain will work (taken from the Near Nightshade paper Figure 17) though take note: " A shard chain must have at least three validators and store all relevant account state. Validators may be automatically or manually rotated between shards through a validator schedule in the epoch block. Erasure coding is used to distribute account state from one shard across validators in other shards so that the data is still available even if all validators within a shard fail. "
1 reply
0 recast
0 reaction

Samuel pfp
Samuel
@samuellhuber.eth
THE BEST PART IS SYNC!!!! Why? First because if you run a read hub then you can now subscribe to only the shards (set of FIDs) you care about!!!! and not recieve traffic or anything else for what you don't care about (if we are at per FID sharing, not today but likely later) AND you can check for real! if you have the latest state so a readyness check can be made to see if that hub should be read from or not! Lovely for any K8s user <3 as K8s can handle all that routing complexity just based on you defining a readyness check
1 reply
0 recast
0 reaction