Contenu source (brut)
<h2>Introduction</h2><p></p><p>Blockchains are built on lies. That is, <em>polite lies</em>,<em> </em>manifesting in layers of abstraction. There is a world the developer sees, one filled with SDKs, APIs, and frameworks that promise speed and safety. The reality is much more nuanced, littered with registers, syscalls, and bytecode—a reality in which only the maniacal dare to step foot in. In actuality, every abstraction is overhead, and every compiler hides the truth.</p><p><a href="https://github.com/deanmlittle" rel="noopener noreferrer" target="_blank"><span style="text-decoration: underline">Dean Little</span></a> has spent his career navigating these lies, seeking truth by soldering circuits and flashing EEPROMS. With Bitcoin, he built mining pools, GPU kernels, and SPV tooling, staying as close to the machine as possible, and learning the potential of distributed systems that they could never quite deliver at the time. Then, he found Solana, where he is known for his heresy: <a href="https://www.helius.dev/blog/sbpf-assembly" rel="noopener noreferrer" target="_blank"><span style="text-decoration: underline">writing assembly</span></a> by hand, disrespecting compilers, and abusing syscalls—not because it’s fun, but because speed is truth.</p><p>As Chief Scientist at Zeus Network, he implemented the entire Bitcoin protocol from scratch on top of Solana, enabling the seamless flow of BTC liquidity. And, in a troll-proof flex against quantum FUD, he engineered a Winternitz One-Time Signature vault, with the ability to migrate tens of thousands of assets per second, while others merely dream of six. </p><p>Yet, Dean is also a teacher. From Turbin3 to <a href="https://blueshift.gg/" rel="noopener noreferrer" target="_blank"><span style="text-decoration: underline">Blueshift</span></a> and his recent work as DevRel for the Mandarin and Cantonese Markets team at Solana Foundation, he pulls developers into a world most will never see. He’s taught hundreds of developers to ship on-chain, often in their own languages, starting from scratch. His tension is constant: pull people up with abstractions, then push them down toward the machine. </p><p>I wanted to understand what it means to live in this tension—between education and experimentation, abstraction and assembly, writing code for humans and writing instructions for machines. This interview is about that dialogue and what it means to talk directly to the machine when everyone else is talking past it.</p><p>This conversation has been edited and condensed for brevity. </p><hr/><h2>Interview</h2><h3>Origins and Worldview</h3><blockquote><p>You should never just accept limitations. You should push against them in creative ways people haven’t thought of. That’s the philosophy I’ve carried into my work on Solana.</p><cite>Dean Little, Syscall Abuser, Quantum Cat, Curator @ Blueshift</cite></blockquote><p><strong>Ichigo: Long before Solana, you were repairing hardware, flashing EEPROMs, and writing embedded control systems for rockets. How did working so close to the metal—literally with soldering irons and firmware—shape your worldview as a builder?</strong></p><p>Dean Little: I learned to solder when I was about ten years old. I grew up doing microprocessor and microcontroller stuff, and then moved into web and mobile development before eventually joining a rocket startup in Norway.</p><p>Working on mission-critical embedded systems teaches you a few really important things. First is attention to detail—because if something fails, it can go very wrong very fast. Second is simplicity: simple, fast, and easy-to-understand systems are usually better than something overly complicated. And third, you learn to think adversarially. </p><p>For me, working on ballast controls for oceanic rocketry means constantly asking: what happens if this controller fails? How do we detect failure? What backups do we have? What if our attitude control is wrong and we think we’re pointing up when we’re actually pointing down? It forces you to design for failure rather than assuming things will always work.</p><p>Another thing you learn is not to trust other people’s work blindly. That applies to software and hardware. Hardware manufacturers change specs, procurement might accidentally buy the wrong part, and suddenly, nothing works. There are so many things that can go wrong, and it only takes one small mistake for the whole system to fail. <em>That mindset has stuck with me ever since</em>. </p><p><strong>From there, your career quickly led you to Bitcoin. You worked on mining pools, GPU kernels, SPV tooling, and later Twetch. What did those years of working on Bitcoin infrastructure teach you about building distributed systems at scale, and about the limitations of blockchains at the time?</strong></p><p>I went full-time into Bitcoin development around 2017. I built across multiple blockchains—Bitcoin, EOS, and a few others that were popular at the time. With Bitcoin, I started out just using it, but when the fees spiked really high, it basically became unusable. That was the first real rush of retail into crypto, and what I realized then was that once the fees spike, the blockchain becomes useless.</p><p>That experience made me rethink the so-called “scalability trilemma.” Honestly, it’s a bullshit made-up problem. Even back in 2017, we could send 4MB photos across the world in under a second. It seemed ridiculous to believe blockchains couldn’t scale beyond 1MB blocks. <em>The limitation wasn’t physics—it was design</em>. </p><p>Because Bitcoin’s base layer is so constrained, you’re forced to innovate in other ways. I ended up diving deep into Secp256k1, building solutions for hiding execution results in signatures. It was a kind of crude verifiable compute, long before ZK started to really take off.</p><p>Those years taught me that running a Bitcoin company is really running an infrastructure company. Bitcoin’s protocol can do a lot, but the node software is limited. The UTXO model is great for parallelization since state is segregated, much like Solana accounts, but it’s terrible for shared state and indexing. On the other hand, Ethereum’s account model is great for shared state but terrible for parallelization. What clicked for me with Solana was its segregated account model—it combines UTXO’s parallelization with the usability of Ethereum’s global state model.</p><p>My big takeaway from those years was that systems often fail, and thus, they should be designed to fail gracefully rather than catastrophically. <em>You should never just accept limitations</em>. You should push against them in creative ways people haven’t thought of. That’s the philosophy I’ve carried into my work on Solana.</p><p><strong>Now, a lot of people know you in the Solana community as the guy writing assembly and disrespecting compilers. Why stay so close to the machine? Why not focus more on improving higher-level abstractions since that’s where the majority of the developers will be building?</strong></p><p>Contrary to popular belief, I’m a contributor to <a href="https://www.helius.dev/blog/an-introduction-to-anchor-a-beginners-guide-to-building-solana-programs" rel="noopener noreferrer" target="_blank"><span style="text-decoration: underline">Anchor</span></a>, <a href="https://www.helius.dev/blog/pinocchio" rel="noopener noreferrer" target="_blank"><span style="text-decoration: underline">Pinocchio</span></a>, Agave, <a href="https://www.helius.dev/blog/alpenglow" rel="noopener noreferrer" target="_blank"><span style="text-decoration: underline">Alpenglow</span></a>—basically everything. I’ve worked on cryptography, SIMDs, and low-level programs, all across the stack. </p><p>The biggest thing with Solana development is that everything outside of on-chain programs and infrastructure is totally permissioned. It’s almost impossible for me to get my PRs merged into any official repo. But on-chain programs? <em>I can do whatever you accidentally a
