In this article I'm going to explain my recent efforts in reimplementing Tendermint from scratch. Overview. Tendermint is a byzantine fault tolerant consensus protocol. The network is 3F+1 nodes, with the allowance for F byzantine failures. In the base case of F=1, the network must have 4 nodes. The network decides on a single value via the consensus algorithm, at an interval bounded by a timeout. The network communication cost is $O(N^2)$, as each node in the network must gossip to every other node.

The Etch L2 is a bitcoin rollup. Product. add a mechanism to post EVM transactions to bitcoin develop a node which tracks bitcoin L1 for these EVM transactions, and ingests them and runs an EVM L2re-engineer some EVM things: fixed gas allowance, direct mapping BTC address <-> EVM accounts, eliminate nonces etc., fix the gas price build a bridge to move L1 BTC to L2 BTC (see here) deploy a bitcoin stablecoin protocol (dai-style), bitcoin lending protocol, and a bitcoin name system protocol

An innovative new design for a bridge. Context. What is a rollup?. A rollup is a blockchain scaling technology, where you use one blockchain (the layer 1 - L1) as a settlement layer for storing the "rolled up state" aka a state root of a second blockchain (the layer 2 - L2). The scalability comes from being able to process transactions off-chain from the L1 on the L2, and instead only paying the cost to settle the state of the L2 to the L1. Its security is based on making claims of the state root's validity via ZK validity proofs or optimistic fraud proofs. What is a based rollup?. A based rollup is a stupider term. Instead of using the L1 to post a state root, we use the L1 as the sequencer for an L2. Meaning - you just post your L2 transactions to the L1 and the L2 network executes them. Hence the rollup is "based". (It's stupid because there is no rollup at all, it's more just execution rolling up). There is one key advantage to based rollups - they are wholly secured by the L1 base chain. Since the L1 performs sequencing for the L2, there is no separate sequencer (like Optimism) or consensus set (like all the Tendermint-based Bitcoin L2's). We are building an EVM L2 based on Bitcoin, where users post EVM transactions to Bitcoin mainnet (L1) and they are executed offchain by the L2 network.

https://twitter.com/liamzebedee/status/1688728259402588160 https://liamz.co/tech-blog/2023/07/10/on-cryptonetworks-vs-federated-hubs-and-p2p.html gigapass summon bittorrent swarms to host datasets, on-chain buy capture-resistant hosting from a protocol, not a company problem:

Abstract. Problems this addresses: Decentralized blockchain RPC (aka decentralized Infura). Decentralized high-speed CDN's / BitTorrent. Prototype. take eth-verifiable-rpc https://github.com/liamzebedee/eth-verifiable-rpc generate a STARK proof of each result setup a two-way payment channel between nodes

Concept. Imagine a conversation between two people, over DM's (direct messages). This conversation has gone on for years, and has a lot of context. Now imagine we simulate this conversation using an LLM. A ChatGPT model is tasked with predicting future conversational messages. The LLM functions like Deep Blue's chess computer - it simulates all possible conversational paths between two people (or at least as many as is tractable). Now this DM is ongoing. All messages the LLM hasn't seen can be scored according to the prediction error. This is a fun test of agency, free will and determinism. If you can have a chat about something the LLM didn't predict, you are moving forward! Reverse that entropy, baby.

UPDATE: I was wrong, Infura doesn't censor RPC reads! This post caught the eyes of Infura, and they set out and wrote a blog post which you should check out. Although, the party isn't over yet. The option to censor is still there unless we use secure RPC. Which is why I ended up building out this, check it out- https://github.com/liamzebedee/eth-verifiable-rpc Liam Zebedee (@liamzebedee). This is a spec, a request for either (1) grants or (2) builders. Please reach out on the Twitter thread / over DM's if you're interested in either. Introduction. Recently, Ethereum node providers like Infura/Alchemy started censoring parts of the Ethereum database from being read via the JSON-RPC API's. This proposal is to programatically detect this, by building a local EVM shim that verifiably loads state from a remote node during execution.

Index for a book I'm writing. Write out a book.Explain how ZK-STARK”s work from the ground up (video/whiteboard).What is the anatomy of a STARK proof Explain how Cairo, VM, computers etc. work. Megathread deepdive: covers state machines, prover-verifiers, VM's, the cairo language, how STARK's work, arithmetization, the Cairo machine, computation compared with EVM (addition), public memory, memory holes, Cairo runner/bootloader Explain how recursive STARK’s are so powerful.

Trends and observations: the "metaverse" real names are archaic (cc: Matt from Paradigm) anons fbifemboy knows more about FTX news than mainstream media (commentary) open lore

When I was like 12, I played Guild Wars. It was an incredibly low fidelity web game - you had to refresh the web page to see where people were building armies and so on. But the mechanics were really fun - forming alliances with random internet people. You might think games have to be complex but no - it was literally a text box chat, with a bunch of buttons like "join guild", "leave guild", and then an ability to give each other titles - like "head of military", etc. And being part of a guild - you could start wars. LOL So I remember one time we went away camping at the beach (Australians), with no internet, and my guild member had like invaded these neighboring cities. I only found out when I got back, I'd lost like 99% of the effort I'd put in because of this guild member and so I promptly fucked off and made my own guild hahahha. Started recruiting people, etc. Gaming is such a weirdly powerful thing because it was probably the first place I got responsibility and agency as a kid.

This was a question I had while analysing how to implement recursive proofing, otherwise known as a STARK verifier inside a provable environment. Thank you to: Louis Guthmann for helping connect me and answering my early questions around STARK's and SNARK's, as well Kobi Gurkan (who explained R1CS to me), Th0rgal_ for volunteering to tutor me on the polynomial maths, Alan Szepieniec for his fantastic public guide on STARK's. Background. Turns out, STARK's are really simple! Here are some topics and concepts that will come up during your explorations. constraint systems, satisfiability Fun question - how do you convert a program into a set of equations?

By Liam Zebedee (@liamzebedee aka SugarLord). Context: Loot Assassins and their fog-of-war problem Intro. If you've ever played Age of Empires, Guild Wars, or any other real-time strategy (RTS) game, you know it's a fun time. Gathering resources, assembling armies and then plotting attacks against other players is awesome - and it's especially fun given a multiplayer environment, what sorts of strategies emerge. In recent years, money has become more a part of online gaming than ever before - for example, EVE Online's $1M+ battle. The natural question to ask is - why not on-chain? Blockchains are in essence, an open game platform, where anyone can permissionlessly build new game items and lore. Imagine a version of World of Warcraft, where anyone could create their own quests, with their own items, game mechanics, and so on. This is being made today in a project/network called Loot / the Lootverse. What's more - blockchains connect you with a wide range of infrastructure - simply implementing a game that adheres to the ERC20 standard for currency, or the ERC721 standard for items, means your game's items and currency are automatically displayed in a wider web of apps - users can show off their character's items in social networks like Farcaster, they can trade items on Uniswap or OpenSea, and much more. The challenges with building rich on-chain games really fall into a couple of categories:

How do I understand recursive ZK proofs? / A better way. By Liam Zebedee (@liamzebedee) and XYZ Acknowledgements. This came directly out of convos with Lord from Biblioteca, Francesco from Apibara, Guiltygyoza, in the entire StarkNet hacker house at ETHLisbon 2022. Thank you to them, and the organisers of that house. PS: Don't feel scared by the length - the sections are designed to be skippable. Part 1: memoization. In JavaScript, we have a common optimization pattern called memoization. For those not familiar, memoization is kind of like caching the results of calling a function, so when you call it again with the same inputs, you get the result from the cache.

Gliss protocol tokenises attention (like BAT) and influence in social media. In doing so, we build a platform where it is possible to get financial exposure to a profile's growth in influence - a fame derivative, which is used to incentivise the network to self-discover and fund early and unknown artists. 0. Origins. Introducing the follower derivative: Maybe one idea for this is something like a derivative instrument based on the number of followers. You buy a derivative which goes up in value according to how many followers a user has. But what would this derivative be able to be exchanged for? Say everyone’s social feed had a token which represented their attention. So you could buy a person’s attention token and use it to pay for ads in their feed.