Back to Basics: Why the KISS Principle is Still the Golden Rule.

Keep It Simple, Stupid

This phrase is the core principle of Linux kernel design, a point often forgotten amidst the current trends in frameworks and designs. Recently, particularly in the DHT blockchain projects I've been more involved with, I've encountered numerous issues of over-engineering. This fancy new technology of blockchain too easily blurs focus. I fell into this trap myself recently, and I'm writing this on my new site as a reminder.

# The DHT Underbelly Trap

Recently, I've been deeply affected by DHT projects, so let me elaborate.

Most blockchain projects, when designing, create a relatively complete DHT, meaning a distributed storage system. The entire table is formed by multiple users, and from this starting point, teams begin selecting their consensus algorithms and designing communication protocols. This is precisely where the trap lies. Why?

The trap stems from the fact that designs are often not standardized, perhaps due to the origin of P2P nodes, or because of the choice of writing to a bottom-level data format that is new but quickly abandoned (like special protobufs, an example without targeting anyone XD). These traps are easily stepped on right at the project's inception.

I recently read an article, Smaller is Better ↗, explaining their design's predicament of wanting everything. It quotes, " No one wants the Nginx team to release Postgres." They then focused on designing the DHT transport layer, concentrating on building reliable synchronization. Overly complex features make integration and compatibility difficult; massive beasts are built from simple designs.

This reminds me of a recent GitHub interview with Linus. In it, Linus designed Git simply as a scripting solution to replace CVS, with core functionalities completed within weeks. Over the years, he has mostly used core features like git blame and git log. Primarily, he used the SHA1 design to solve long-standing issues with patch merging. The core functionality revolves around solving this problem, then designing the fundamental version control features. He even leveraged its inherent characteristics to create local Git trees. I believe he is the most admirable tool for distributed systems today.

After understanding Git's design philosophy, it was a revelation. This is precisely the problem most designers face today. They simply need to focus on designing a tool that solves a problem. It's okay if it's a script, as long as it's useful enough, it will quickly become a valuable component.

# Blockchain Projects Are Reinventing the Wheel, Not Focusing on Compatibility

Most people online are criticizing the Ethereum Foundation. Personally, I feel this sentiment might be leaning towards the perception of Ethereum's ineffectiveness from a user's perspective. Recent upgrades like EIP-4844 (Blob) and EIP-1559 (Gas) personally haven't significantly impacted user experience. Instead, they have further fragmented the overall EVM ecosystem experience.

Before delving into this, let's consider why the Ethereum Foundation acts this way. I personally believe it's because they focus more on core EVM development. After all, in the blockchain hierarchy, those working on the underlying layers can look down on others (jokingly, most core developers are excellent). This leads to the current situation where application layers seem to have stagnated compared to when Ethereum first launched. It's quite lamentable. 6-7 years ago, we used UniswapV2 on-chain, and we still use the same model today, perhaps just with different tokens or Swaps.

Many projects that interact with core developers want to build their own blockchain without focusing on compatibility. This inadvertently makes Ethereum the de facto developer of compatibility for these projects, leading to the current situation where L2s have more prominent DeFi projects.

Whether it's P2P projects or blockchain projects, I see them all creating increasingly complex algorithms, then setting up cross-chain bridges to Ethereum to siphon liquidity. In essence, Ethereum's biggest application right now is that slew of blockchains that look identical to it. New DHT systems are also largely following the path taken 10 years ago: quickly launching a blockchain with a gimmick before an ICO. Now, blockchains might not be fancy; they might need to invent special methods, claim to be fast, and be compatible with Ethereum.

Despite all I've said, I still like Ethereum very much. However, this article discusses a minor issue I perceive in the ecosystem. Most people's design philosophy is to identify customer problems and solve them. Yet, they often end up stepping into the same pitfalls others have before, leading to an overabundance of homogeneous DHT or blockchain products. This was especially true during the era of one-click chain deployments, turning many simple problems into very complex ones today.

# From Complexity to Simplicity

So, what do I consider good design? Everyone marvels at Git, finding it brilliant. Nginx and Postgre are also beautifully designed products. If we focus on what they do, they provide stable, simple, and user-friendly tools compared to other similar products.

I've now delved into DHT systems and have fallen into the trap of wanting to design a P2P system to solve my specific requirements. However, blockchains are already excellent DHTs. Would using existing blockchains like Sui or EVM with ZK be better than redesigning a self-hosted node model? From a user's perspective, absolutely. Web3 has no shortage of complex applications, and many events require payment to learn. Therefore, from a user's standpoint, not running your own node not only saves you trouble but also saves users trouble.

What I haven't figured out yet is a simple yet disruptive design like Git's. However, I believe simplicity at the core is a crucial philosophy. After all, if users are faced with a complex tool, I imagine the audience will become increasingly complex and peculiar. I take this as a warning, hoping not to create a colossal behemoth.

This is a personal reflection. At the beginning of the year, I built an entire DHT system, even bringing in WASM to allow P2P to run easily anywhere. However, complex type validation, message processing, and synchronization issues forced me to look for similar products. I discovered that a simple WebRTC could handle 90% of my tasks elegantly, leaving me quite embarrassed. My months of effort felt wasted. This is also a part of personal growth!