While this perspective is not wrong, it resembles Maslow’s hammer: “If all you have is a hammer, everything looks like a nail.” Decentralization is that hammer, and social applications appear to be the nails.

Let’s think it another way. Instead of thinking about what kind of social applications decentralization can bring, we should ask: if we have a decentralized social network, what products can we build based on this network? Thanks to Farcaster, we already have such a network, although it is still small. I would classify all products or protocols built on decentralized social networks as decentralized social, even if the product itself is centralized or not a typical social application.

To answer “what can be created based on decentralized social networks,” we first need to answer: when we have a decentralized social network, what do we have? At least, we have decentralized data, decentralized relationships, decentralized identity, and we can undertake decentralized development and construction. This article will explore the possibilities of decentralized social from these perspectives.

Decentralized data often reminds us of data ownership and privacy, which might be achieved in the future. At this stage, decentralized data merely means that the data created by users no longer belongs to centralized companies (which is already revolutionary). However, this data doesn't belong to the users either; it is a commons that everyone collectively owns and can use. Three types of products will emerge first on this data commons.

First type: information services and media services. These refer to how data/content is re-presented to users. For instance, client based on different feed algorithms. As @liang mentioned, “The feed algorithm should be a protocol. Good opportunity for builders.” I completely agree. Additionally, information search and processing services combined with AI, such as some existing products on Farcaster, fall into this category. On a smaller scale, channels with the main feed strictly controlled by hosts are essentially media services.

Second type: products and product marketing based on user profiles. These involve analyzing data to create user profiles and providing users with products based on those profiles. The most familiar products in this category are advertisements, which are the commercial core of Web 2.0. However, in decentralized social networking, advertisements are merely one type of product. Thanks to embeddable frames and programmable feeds, social feeds are no longer just streams of information, but also streams of products, or even, as @raulonastool mentioned, “feed-as-an-interface.” With products appearing directly in front of users without needing advertisements for redirection, and data being open rather than closed, these two changes will usher in a new era for products and product marketing based on user profiles.

Third type: content incentivization. This involves pricing data/content and bringing economic returns to data producers. There are multiple design approaches for such products. For instance, tipping (Degen and Build); bounty platforms (Bounties and Rounds); cast trading (Jam); channel incentives (far_terminal),… This category of products might solve the content incentivization issues that have long plagued Web 2.0, but we also need to be wary of problems arising from excessive financialization.

Just like our data, our social relationships have shifted from closed to open, from private to shared. Based on decentralized social relationships and decentralized social graphs, four types of products may emerge:

First type: products presenting social graphs. In the Web 2.0 era, products precede social graphs, making it difficult for users to switch to other similar products once they establish social relationships. However, decentralized social networks make it possible to build products on existing social graphs. These products present social graphs in various ways to meet users’ different needs for social spaces. For example, a product that presents each node in the graph equally creates a space closer to a “plaza”; a product that organizes content around the user's own node creates a space more like a “tiny corner” and “warrens”. Designing social spaces is akin to architectural design in the offline world. As we spend more time online, the design of these spaces will become increasingly important and diverse in demand. (In “The Evaporative Cooling Effect”, @bumblebeelabs analyzes the basic patterns of social spaces, suggesting that “plaza” and “warrens” are the two fundamental patterns).

Second type: utilizing social relationships for brand development. @v pointed out a fact that many people may not realize: “Centralized social networks closely control their users’ ability to reach their audience. But reliably reaching an audience is valuable to users.” This control hinders users from leveraging their social relationships to develop their brands. Decentralized social networks change this situation, turning users’ social relationships into their social capital. Utilizing social relationships to develop personal brands may become common practice. There will also be products to help users achieve brand development, such as Hypersub. Each subscription product on Hypersub represents a brand, which could be an information service, digital work, or even a physical product. For instance, I’ve seen @samantha working on a candle brand.

Third type: products based on social graphs. The most anticipated products in this category are social network games, which were once extremely popular. Social network games bring offline social relationships online, attracting many new users to social networks. New opportunities for social network games include open social graphs, decentralized development, and the financial attributes or investment/speculative nature brought by blockchain.

Fourth type: products using social graph data. Social graph data can help users and companies find target audiences, establish connections, and expand their social and other relationship networks. There will be a need for professional products to assist in this process. For instance, I tried a frame on Farcaster to find new friends and successfully connected with some recommended users. Besides, social graph data can also be used to create user profiles; it is the most valuable type of data created by users, a veritable gold mine.

Decentralized identity represents the user’s digital self and the proof of their digital identity. It defines the user and determines their permissions and entitlements in the network space. There may be three types of products related to decentralized identity:

First type: products related to establishing decentralized identity. These can range from large reputation systems like Talent to smaller badge products like Power Badge. Second type: incentive systems related to decentralized identity. An example is Moxie, which aims to implement economic incentives at the protocol level. Third type: products related to the use of decentralized identity. Such as making identities available for social gating, for sybil detection, and for online and even offline verification related to entitlements.

Blockchain plays a crucial role in the development of identity and incentive products. It establishes ownership, enables the tokenization of content and social capital within the social network, and provides a permissionless, trustless marketplace.

When we have a decentralized social network, we gain decentralized data, relationships, and identities. We can come together in a decentralized, autonomous manner and engage in composable development and construction based on this network. This is not about combining blockchain with social, nor is it about deriving Web3 from Web1.0 and Web2.0; it’s about growing an entirely new ecosystem on an entirely new foundation.

People often ask, “Why hasn’t Web3 social taken off yet?” I believe the main reason is that this decentralized social network is not large enough yet, and the network effects haven’t even begun to take place. Unlike the isolated and competitive social applications of the Web 2.0, any product that succeeds on a decentralized social network will expand the network, and this expansion will benefit all products based on the network, making them more likely to succeed. Therefore, although it is challenging to rebuild social relationships, if we maintain an open, co-constructive attitude and focus on growing the network rather than exploiting it, every product and every construction can push the network forward a little bit. The aha moment will come sooner or later.

as it originally appeared on t2：
https://app.t2.world/article/clye7lkwn36464922mcyolmbi0q

Covenants are an old yet fresh topic. As early as 2013, developers began discussing this topic, and in recent years, multiple BIPs aimed at implementing covenants have been proposed, sparking intense debates and making it one of the hottest topics.

Covenants warrant serious discussion due to their powerful capabilities. They are considered to bring new possibilities to the programmability of Bitcoin and are believed to enable smart contracts. For Bitcoin, this is undoubtedly a double-edged sword. In this article, we will explore what covenants are, how they work, their robust functionality, and their significance for Bitcoin. While discussing details, this article often uses CTV as an example, but CTV is not the only method of implementing covenants.

This article delves into the exploration of covenants but also magnifies a slice of Bitcoin under a microscope for observation. Through this observation, we can understand how Bitcoin operates at a granular level, comprehending both its capabilities and limitations. Understanding what it cannot do is as crucial as understanding what it can do because only then can we choose the right path for building on Bitcoin.

1.

Hua: Before discussing covenants, clarifying two issues related to Bitcoin may be necessary, which can help us better understand covenants.

We know that Bitcoin uses a scripting language, and it is known that scripting languages support the implementation of smart contracts. However, in reality, smart contracts have not been implemented on the Bitcoin main chain. This inevitably creates a sense that implementing smart contracts on Bitcoin faces some insurmountable obstacles, and it seems impossible on the Bitcoin network.

However, many people may not be aware that although Bitcoin can be programmed using a scripting language, the set of opcodes is extremely limited. This limited set of opcodes restricts the programmability scope of Bitcoin, meaning that, although the scripting language can implement smart contracts, programmers do not have sufficient "tools" to implement smart contracts.

Poly:

Definitely, Bitcoin Script can be considered limiting as it can only perform the basic operations such as making simple payments. Some of the reasons that people may find it “limiting” is that it doesn’t have a global state, it’s not considered turing complete, it uses a UTXO-based system (which has “value blindness”) instead of an account-based system. The last big reason is that very little data from the blockchain itself can be integrated into contracts causing blockchain-blindness.

This has created a lot of challenges over the years as people have worked around these limitations. We’ve also had a semantic shift with the term “smart contract” to mean one specific thing when you should consider the lightning network a production of many smart contracts formed by many individuals. Those multi-sigs with hashlocks and timelocks are not only smart contracts, but also have time-based covenants.

The problem is, just as you mentioned before, because Bitcoin only has simple opcodes to perform just the basics, if you attempt to scale beyond two people in a smart contract, you can get either a lot of bloat for an on-chain footprint or the things you want to do just might not be possible. This strict limitation comes from a few places, I think the biggest being that when the inflation bug occurred back in 2010, Satoshi had disabled a whole list of higher order opcodes including OP_CAT which would’ve allowed us to create more dynamic smart contracts via transaction introspection.

BCH has since overcome this limitation within their own script, showing that Script isn’t as weak as everyone assumes, just that Bitcoin has always been slower due to its decentralization and coordination is near impossible except over long periods of time. We’ve also barely touched on Taproot and Tapscript which will alleviate a lot of the footprint concerns and allows for new behaviors such as BitVM by rolling up the contract into the signature and you only reveal as necessary.

Hua: Why are there strict limitations on opcodes? Can you use OP_CAT  as an example to help us understand this point?

Poly:

So OP_CAT is deceptively simple, it will take two strings and add them together. It was originally disabled because it had resource issues and could be used to cause nodes to crash, but I’m not sure if that’s the full story as Satoshi set the 520 byte stack limit and disabled OP_CAT in the same commit so there could be more to it than just simple resource exhaustion.

But just to give a short list of what OP_CAT can perform: CTV/TXHASH covenants, verify SPV proofs, double-spend protection for 0-conf TXs, 64-bit arithmetic, vaults, quantum-resistant signatures. The list goes on, with OP_CAT alone, it can emulate both CTV[CheckTemplateVerify] and CSFS [CheckStackForSig] style transactions. The only issue is it’s highly inefficient in the manner that it performs these actions that might be possible, but that could just preclude these transactions from being desirable except by users of scale such as custodians.

Hua: Let's talk about another "limitation" of Bitcoin. Bitcoin only supports "verification" as a form of computation and can't do general-purpose computation.

We also know that, for example, smart contracts on Ethereum contain rules for state transitions. It completes the state transition through computation, enabling the functionality of smart contracts. In comparison, Bitcoin can't do general-purpose computation, meaning it cannot achieve state transitions through computation on its own.

Is my understanding correct?

Poly:

Yeah, I’d agree that’s a simple summary of the current state of things. Bitcoin could be made to support computational transactions and the line can become quite thin when covenants and state transitions are involved, but those proposals aren’t as well researched and might not be something that’s considered desirable.

I’m actually not that much of a fan of the way Ethereum does things. Due to it being computational in nature with the verification built on-top, if I attempt to perform a trade, my window could shift and I could “fail to trade” but the transaction for the attempt to trade was still valid so i still paid for fees which wasted my money on what i’d want to consider a failed transaction and wasted blockspace for someone else. Another weird aspect are the Oracles in Ethereum. Oracles must pay gas to update their oracle prices whereas in Bitcoin DLC’s, the Oracle are blinded and are just providing a signature and can’t be “pinned” due to a change in fees nor can Oracles target specific contracts.

Earlier I discussed all the downsides to the UTXO model compared to the account model and global state model, but what allows the UTXO model to shine is parallelism. The only concern you have is the child transactions to the same UTXO, nothing else matters, this allows the system to scale much better.

2.

Hua: Let's start discussing covenants now. What are covenants?

Poly:

Covenants usually refer to restrictions on how coins can be transferred. The word covenant seems to carry some sort of connotation with it so it helps to demystify it and explain it as simple locking mechanisms you can place only on your own coin.

We have two covenants already inside Bitcoin and they power the Lightning Network, CSV [CheckSequenceVerify] and CLTV [CheckLockTemplateVerify]. Some just call these opcodes “smart contract primitives” as they’re simple time locks, but they can also be classified as time covenants.

CTV [CheckTemplateVerify] is a proposed Bitcoin upgrade and is included in BIP 119. It is different from CSV and CLTV, you can think of CTV as a “TXID [Transaction ID] lock” or “UTXO lock”, only these TXID’s can be made from this lock. For CTV, we refer to this TXID lock as “Equality Covenants” as the resulting transactions must equal to the original transactions that were committed. It’s also called a deferred commitment covenant, as you can see that your UTXO has been committed to, but it isn’t yet placed on-chain.

The most known alternative is SH_APO [Any Previous Out or AnyPrevOut] which focuses on the payout commitment being ensured while allowing the pay-in method to be flexible. A few others discussed are OP_CCV [also known as MATT], OP_EXPIRE, TXHASH and TEMPLATE KEY.

Hua: When you mention "covenants usually refer to restrictions on how coins can be transferred," can I understand it like this: Covenants are a method of specifying how funds can be used, or in other words, it's a way of restricting where funds can be spent.

Poly:

Yep, it effectively earmarks the UTXO to be distributed in a specific manner, once you commit to it, you can't take it back, it's now consensus bound, and only its new owner can decide how to spend their funds.

When a UTXO is created on-chain, our instinct is to assume that a single private key is holding that UTXO in place. But if it was a CTV bound UTXO, when the UTXO is spent, you'll see an extra 32 byte hash paired with the new transaction that represents the hidden state that was inside the original UTXO.

Hua: You've mentioned "TXID lock/UTXO lock" multiple times. Can I understand it like this: To understand how CTV achieves their functionality, we need to understand what TXID lock is and how it works. TXID lock is a key mechanism.

Poly:

Yes, It creates a strong foundation to build further schemes. The TXID is determined by the contents of a tx. And if you can add inputs to a tx, you can manipulate the TXID. CTV makes you lock the number of inputs and outputs. This is how we ensure that CTV commitments are trustless, if the TXID could be malleable, you could potentially be able to steal someone’s funds. Once you have a TXID locking mechanism, you combine it with other locking mechanisms such as the time locks to build even greater smart contracts.

3.

Hua: Why do you think covenants are a rabbit hole?

Poly:

I call covenants a rabbit hole because there’s so much you can do with simple restrictions on transactions such as a time lock or a TXID lock. We’ve managed to build the entire Lightning network with simple time locks and while it isn’t perfect, it is the only truly decentralized L2 in existence. I don’t like how it’s slowly shifting towards being custodial focused, but that’s exactly why I’ve started down this rabbit hole to begin with: To make our smart contracts more powerful. We refer to the TXID lock as a Template. With Taproot, we gained the ability to have signature aggregation. With Templates and CTV, we gain the ability to have transaction aggregation.

CTV serves as a replacement for a pre-signed transaction oracle, which eliminates the trust and interactivity requirements needed to create more sophisticated smart contracts that are needed for things like vaults and payment pools. The vaults and payment pools that you can make with CTV are technically possible today, but currently they’re precluded by the trust or interactivity needed to make it work. Moreover, with CTV, we can build channel factories, additional layer 2 solutions such as Ark, Timeout-Trees, Stakechains or Surfchains, and JIT fidelity bond solutions such as PathCoin.

Probably my favorite feature is Non-Interactive Channels [NIC’s] that we’ve also been referring to as Cold Channels. The basic idea is to take a normal lightning channel and simply place it in a CTV template. What makes this different from a normal lightning channel is that neither party actually needed to be online to create this channel. So if I need a channel with another person, I don’t need them to be online to create it, I don’t even need to tell them I made it until I’m ready to spend from it! This allows for cold storage capability on lightning because I don’t need a watchtower nor a node to safeguard my funds in any channels that aren’t yet active. Third-party coordinators can also establish NIC’s for two individuals so there’s a lot of flexibility in what’s possible.

As it stands, CTV won’t allow you to build a DEX on-chain, but I’m not sure if that is such a bad thing as people are currently trying to build DEX’s off-chain using the Lightning Network as it is today. I think this ties back into the “Verification vs Computation” discussion, how much do you really want on-chain versus how much do you need to verify on-chain. One concern I have about on-chain DEX’s, besides the excessive on-chain updates driving higher fees, is MEV. We’ve already spotted some MEV from BCH’s DEX’s transactions and as the market matures, this is bound to get worse.

Hua: Can you give an example to help us understand how CTV works?

Poly:

Let’s say I am expecting to receive 5 BTC, as of right now, the only thing I can do is receive the payment and verify it on-chain. With CTV, I can commit to future addresses or to people and reduce it down to a simple pubkey that I give to my payer to pay me. They don’t know the details of it so it remains private to everyone but me. Once I can confirm that they’ve paid me, all of the actions I took using the CTV template have now also taken effect.

So if I had elected to create a channel with Bob, once Alice pays me, the channel with Bob is now committed, even though the channel with Bob is nowhere to be seen on-chain, it is only accessible by my template and the transaction that Alice had created. It’s only known to me until I share the channel details with Bob. Once I do share the details with Bob, we can use the channel as normal. When we cooperatively close the channel, instead of needing to place an open channel details on-chain, we just place the closing channel on-chain. This allows us to perform transaction cut-through, reducing the total number of transactions that need to be on-chain by at least half for layer 2 solutions.

The opening portion only needs a commitment, what we really care about are the closing details. If this was a shared UTXO with multiple people, we could collaborate to close our transactions together as well, reducing the number of on-chain transactions even further.

Hua: As you mentioned before, we can introduce different opcodes to implement covenants.

Poly:

So if we re-introduced OP_CAT, I think it would allow for nearly every type of covenant possible as you can emulate any form of introspection for TXHASH. The more limited method would be to introduce opcodes representing the explicit behavior desired like with CTV, CSFS or CheckSeperateSignature. CTV is the ability to do deferred outputs. CSFS is the ability to do deferred signatures so you can defer the payment itself. They sound similar and in fact they work well together as building blocks to enable LN-Symmetry, but the commitments are happening at different levels.

TXHASH and TEMPLATE KEY both enable introspection and serve the same purpose, but TEMPLATE KEY uses a single-byte mode while TXHASH uses multi-byte flags. This allows for much more powerful capabilities inside script and smart contracts, but many are concerned about the side effects it could have. TXHASH and TEMPLATE KEY are more of a CTVv2, something that would make CTV more powerful and expressive.

Hua: I've noticed that there doesn't seem to be a significant disagreement about whether to support the implementation of covenants. However, in comparison, there seems to be more significant divergence among people regarding which method or set of opcodes to add to implement covenants.

Poly:

I think a large part is there’s different camps of thought. There’s a lot of the lack of understanding the intent behind each proposal as they have different goals in mind and are designed in completely different ways.

A lot of developers have only had their eye on Lightning and how it’s to evolve, they tend to favor opcodes like SH_APO since it enables LN-Symmetry. For a lot of developers that don’t particularly like Lightning due to its limitations such as Inbound Liquidity constraints or the requirement to be online, they tend to favor opcodes like OP_CAT, TXHASH as more expressive scaling solutions. The developers that prefer CTV are more neutral and are looking at it from a systems point of view, it doesn’t necessarily do any one thing perfectly but it greatly enhances everyone’s ability to do their preferred thing, whatever it may be without introducing risks that can’t be measured since it doesn’t introduce introspection.

4.

Hua: Before discussing covenants, we talked about issues related to opcodes in scripting language and the problem of limited computation leading to state transition. We already know the relationship between covenants and opcodes. Now, let's delve into the issue of state transition. I'm not sure if looking at covenants from the perspective of "state transition" is correct, but this perspective truly fascinates me.

Without covenants, the scripting language's main function is to retrieve transactions' signatures and verify them. The transaction can only be completed when the private key is correct, and there is no intermediate state. With covenants, a transaction can be completed when certain conditions are met. Moreover, a transaction can only be completed when specific conditions are satisfied (not just the correctness of the private key). Can we understand it this way: Covenants indirectly provide conditions for state transition.

Poly:

The covenant is the template shell or the "state". Inside of it, you're going to need to make time locks and other functions to enable the desired functionality that you’re wanting, be that a vault, lightning channel or some other layer 2 solution.

So CTV allows for the state creation to occur, but you have to dynamically rebuild the state at each transition to keep it in homeostasis, we call this meta-recursive. Whereas something like SH_APO allows you to create a state and then periodically update that state, making it recursive. CTV can also create a chain of transactions that would allow you to “step-through” that state.

A good example to think about is Ark, it’s a giant smart contract, almost like a giant coinjoin and the one running the protocol creates a new state [or rounds as it’s called] every few seconds to facilitate participants to pay others as needed. Once the Ark operator is ready, they will send a transaction to the mempool to commit the current state to on-chain. These on-chain placeholders can be thought of as the “transition states.” The operator has to constantly recompute new states to present to the Ark participants and what’s sent to on-chain is the verification of that state.

Hua: Can we understand it this way: Covenants implement a form of smart contract based on verification rather than computation?

Poly:

Yes. Definitely. This smart contract is just comparing a transaction to an associated sha256 hash. Block speed verification would actually increase since there’s no signature operations.

Hua: One direction of development for blockchains is modularity, including off-chain computation. However, Bitcoin seems naturally designed for off-chain computation, appearing behind but actually leading the way. What do you think?

Poly:

Time is a flat circle. It’s crazy how it seems like we’ve come full circle to what’s wanted in a blockchain. Bitcoin still seems to have some modularity issues and footprint issues. I wish we had better side-chains that weren’t simply multi-sig solutions and used actual cryptographic means to secure one’s funds and allowed for Unilateral Exits. I think that would help push the boundaries on Bitcoin’s modularity. Taproot has allowed for even more off-chain computation with things such as BitVM, which would allow us to compute almost anything off-chain. But unfortunately, it can’t emulate things inside Bitcoin such as CTV so it seems we still have progress to make.

5.

Hua: What possibilities can be achieved by combining covenants with other opcodes like DLC?

Poly:

So DLC’s have a few problems that would be fixed with covenants such as increasing the flexibility of the parameters of the DLC by making many price points [if we’re wagering on the price of something such as Bitcoin]. Another one is that hardware wallets [HWW] can’t interact with a lot of DLC’s, the signing rounds for DLCs and attempting to do it with HWWs causes DLCs to take several minutes to open. With CTV, this delay to enter a DLC can be reduced down to seconds.

Hua: Are there any other points you'd like to introduce to the readers?

Poly:

We went over a lot of concepts, we touched on how it can be used to mitigate excessive blockspace demand and potential ddos attacks. We discussed how people could save space by making Non-Interactive Channels. I think another good one to discuss is the "L2 exit problem". If we managed to get everyone off of the L1 layer and get them onto a large L2, there's currently no good way to get people off that L2 in an expedited manner. We could think of that L2 as Lightning [we call the potential mass exodus on Lightning, the "Thundering Herd problem”], or we could think of Coinbase, Binance or Liquid as the L2. There are people who hold claims to Bitcoin, but their only way to actually acquire that claim is by submitting a transaction to get it placed on-chain. There's millions of people on Coinbase, I have no idea how to get them off of there and onto Bitcoin in any orderly fashion in today's environment. There would be a mempool backlog of 6 months attempting to get people off the exchange. CTV can fix this.

Make an Ark or a Timeout-Tree with CTV. The exchange could even offer the service directly. Everyone could be offloaded from the original "shared UTXO" that was under Coinbase's consensus and pushed into a "shared UTXO" with a consensus of their choice, be it a simple pool or a large Timeout-Tree. This is where it really wrinkles the brain, this was a pure L2 <> L2 conversion. There was no intermediary step requiring me to go down to L1 first. And I can continue repeating this process indefinitely, using any layer of my choice. There isn’t a need to return to the base layer unless I was forced there such as from an uncooperative closeout from my channel or perhaps an unvaulting from my vault. The Ark and Timeout-Tree pitfall is that they have rollover requirements, you have to move your funds every few weeks or months or you forfeit your funds. This isn’t an ideal solution for long-term funds but works great for any short term holdings and larger markets.

I'd like to provide a full list of every concept that’s been developed using CTV and its ability to simply aggregate pre-signed transactions: Non-Interactive Channels, Timeout-Trees, Ark, Darkpools, Payment Pools, Payment Channels, Ball Lightning, Congestion Control, Dpool's, Compaction, Tree Swaps, PathCoin, Stakechains, Surfchains. But don’t think of these as all independent Templates, if there’s a feature of one that you wish to include in another, you can create your own custom Template to try and find your desired behavior.

It originally appeared on BitcoinMagazine：

https://bitcoinmagazine.com

An Interview With Polyd: The Rabbit hole of Covenants

A written interview with Polyd, a Control Systems Specialist and creator of the Enigma Network proposal, on the concept of covenants.

I know some people come to Farcaster, take a quick look, and leave saying, “How is it different from Twitter?” Let me tell you, when you understand the laid-back Friday vibe on Farcaster, you'll see the differences between them.

Farcaster is a city under construction, where everything is currently centered around its builders.

Most of Farcaster’s infrastructure is designed to serve its builders. Similar to Twitter’s posts, the basic unit on Farcaster is a cast; but unlike posts that only offer content output, Farcaster’s frames and actions enable casts to provide much more than just content. Frames are primarily oriented towards the publishers of casts, allowing them to offer applications or services to others through casts. Actions are geared more towards the receivers of casts, enabling them to interact with the cast or the caster. Whether it’s frames, actions, or the potentially upcoming programmable direct casts, these striking infrastructures on Farcaster are like legos handed to the builders, allowing them to develop products in a composable manner on a decentralized social network.

The infrastructures of channels and group direct casts are primarily designed for content creation. Farcaster is exploring the rules of these features and enhancing their capabilities, enabling builders to create content more effectively and comfortably. 

Most of the honors and rewards on Farcaster go to the builders. Tipping is the predominant way of issuing currency on Farcaster, with the most well-known being $DEGEN. Builders, who contribute to the ecosystem and bring value to others, naturally have an advantage in this system. A recent popular project on Farcaster, BUILD, directly rewards builders. Its token distribution method allows each person to nominate three builders to receive $BUILD every day. I nominate builders I know, but most of the time, I nominate the builders responsible for the things I liked that day on Farcaster, even if I didn't know them before. They are rewarded for their contributions to the ecosystem, not for who they are.

Most of Farcaster’s residents are builders. Almost no one talks about politics or gossip. Instead, they discuss how to effectively filter out the noise on social media while preserving valuable information. They focus on building a conducive space for meaningful conversations. Every day, new applications emerge—ranging from apps to frames, actions, and more, everyone contributes to these developments in various roles: as developers, testers, or promoters. People are constantly building, discussing how to build, and creating tools and infrastructure for further construction.

If you come to Farcaster expecting a fully developed city, you might be disappointed. Farcaster is still a city full of scaffolding and bustling builders. However, if you’re here not just to sightsee but to find opportunities, you won’t be disappointed. You can easily become a builder in this city. There are vast open spaces for you to choose from, plenty of tools for construction, and friends to build with. You’ll earn honors and rewards for your contributions.

And you’ll feel a sense of ease on Fridays, knowing you can take a break after a busy week of work.

I’d like to share my experience on Farcaster under the theme “Anyone Can Become a Builder.” When I first joined Farcaster, I immediately created a channel called “/opinion” and started sharing my views there. However, almost no one was interested in my opinions. I realized that this approach was wrong; I shouldn’t just stay in my own corner.

This brings up an important feature of Farcaster’s information filtering algorithm. In most systems, new users are presumed to be real users until their behaviors indicate otherwise. However, on Farcaster, new users are initially marked as NPCs. Only when their behaviors resemble that of real people are they considered genuine users. In many default settings of Warpcast (Farcaster's largest client), content from NPC users or those without a power badge is hidden or does not appear in the main feed. This means that as a new user, my casts were less likely to be seen by others, especially since I was only casting in my own channel.

I needed to reach out and connect with others—after all, isn’t that the essence of a social network? At first, I just greeted people with “gm. ”Some responded, some didn’t. Soon, I discovered new products being introduced daily. I started using these products and providing feedback to the developers, which finally made others “see” me. I felt like a person wandering around a city, offering help wherever it seemed needed. It might not have been significant, but it helped me start integrating into this city. Even though I wasn’t building my own project, I made contributions by helping others build.

After spending some time here, I gained a basic understanding of the Farcaster ecosystem. I began sharing what I found to be good, useful, or interesting new products, as well as my thoughts and discussions on compelling viewpoints. In this way, I not only helped other builders by making their products and ideas more visible but also built my own content.

I don't know what I’ll build here in the future, but without a doubt, I am already a builder. I’ve received generous $DEGEN tips and have been nominated as a builder to receive $BUILD. I’ve met many people and have been recognized by others—I’ve built my own social network.

This is my journey from an observer to a builder, even as a non-developer and infrequent content creator. This is not a mainstream path, but it was naturally formed based on my personal interests. You don’t have to follow my path. What you need to do is stay here and find something you enjoy that also connects you with others. For example, if you’re unsure of what to do but are a meme enthusiast, start by joining the “/memes” channel. You can share memes there, become a builder for that channel, meet friends, and establish your initial social network. 

One day, I found myself playing around on Farcaster until 9 or 10 PM. Feeling the need to relax, I grabbed a bottle of sparkling water from the fridge and opened a bag of chips. As I slumped on the couch munching on my chips, a giant question mark popped into my head: What am I doing? Why do I need to eat chips to relax in the middle of the night? I sat up from the couch and pondered this question. I realized that I wasn’t just playing on Farcaster; I was working for Farcaster.

For instance, collecting and organizing important information on Farcaster and sharing it with others is essentially the job of a media editor. Using new applications and providing feedback is the role of a product tester.

Once I realized this, the image of a city popped into my mind. I described Farcaster as a city at the beginning of this article, not as a metaphor I came up with, but as an image in my mind.

It’s a vast, dynamic city where everyone is contributing to its construction. The unique aspect is that no one is working under someone else’s orders. Instead, they find and complete tasks based on their own interests or skills. The construction of this city hasn’t fallen into chaos due to a lack of top-down management and coordination. Instead, it shows a level of flexibility, creativity, passion, and vitality that centralized systems can’t achieve. This city is rising quickly, built on the independent work of each individual. 

Farcaster operates effectively in a decentralized and autonomous manner for several reasons. These may include:

1. Farcaster is built on decentralized technology.

2. The platform initially attracted a group of dedicated builders who believe in its potential and have fostered a positive community atmosphere.

3. The use of tips for currency distribution effectively motivates individual builders and boosts overall participation.

4. Channels facilitate topic discussions, content accumulation, and help people get to know each other, establishing their initial social networks. More importantly, individuals can form groups within channels to collaborate on specific projects.

5. Frames allow the integration of products directly into the content stream. Frames in the content stream bring together independent developers and disseminators to collaboratively complete product development and operation.

6. Almost everything on Farcaster is programmable, and user data on Farcaster is decentralized and shareable. These two factors together bring composability. Developers can not only collaboratively improve a single product but also combine different products to achieve new functionalities.

7. A social network that efficiently transmits information and products allows individuals to gather information and collaborate effectively.

By the way, we’ve always been trying to establish effective organizations on top of decentralization, and an organization or community implies collaboration. This means that after decentralization, the first issue we need to address is how to collaborate. And to facilitate collaboration, we must enable efficient information transmission.

Returning to the main topic. I want to sit down and write an article about Farcaster, not because of its registered users and daily active users, its investors, or its technical architecture, but because I realize it is an unprecedented city, or rather, an unprecedented form of social organization or operation. Farcaster is far more than just onchain social; it is a brand-new community built on top of decentralized social networks. People not only get information here but also get products and services, which are produced here. People live here,  with their friends; people also work here, with their users and partners.

Remarks

There is a saying in Xunzi’s “Encouraging Learning” that goes, “不积跬步，无以至千里.” It means that without accumulating small distances, it is impossible to reach distant places. (不积跬步，无以至千里: without accumulating small steps, one cannot cover a thousand miles)

This article discusses the small steps of individuals in Farcaster: starting with something you like and can connect with others. It also discusses the thousand miles of Farcaster in my eyes: a brand-new community built on top of decentralized social networks. I hope the article helps you understand Farcaster. However, the most important thing is not to stand at a distance and study it but to dive in. If you encounter any doubts while exploring, just DC me (@AmelieHua). 

This article investigates their differences in "non-physical philosophy".

The development of Bitcoin is hampered by two factors: the small blocks and the need to maintain privacy. When a Bitcoin developer offers a proposal, he needs to consider whether the proposal will lead to a waste of block space or privacy harm. In other words, he needs to write proposals under these two constraints to achieve his goal.

This is not the case with goal-orientated Ethereum. Reaching the goals is its top priority, even if it's at the cost of other matters.

Development with or without constraints varies greatly. Let's compare Bitcoin and Ethereum to two rare rough diamonds: Bitcoin's approach to development is to carve a rough stone while preserving its characteristics, but Ethereum's approach is to carve it in a way that meets the needs of the marketplace.

This distinction will result in two vastly different products. Which one is better? It's a matter of opinion. But for an ecosystem, this distinction may be a blessing, which allows us to enjoy immediate prosperity and look forward to a bright future.

（Note: Why does Bitcoin have small blocks? This is a simple yet very important question. Thinking it through will make it clear what Bitcoin is holding on to.)

The year 2020 saw two exciting cryptographic applications of Ethereum: zero-knowledge proof (ZKP) and statelessness, which contribute to the development of layer 2 vertical scaling and layer 1 horizontal scaling, respectively. I believe they constitute the core technical building blocks that enable the scaling of Ethereum.

Applications of zero-knowledge proof and statelessness require expertise and substantial time and money. However, zero-knowledge proof can be applied to private infrastructure to generate projects that can be financed. The application of statelessness is confined to public infrastructure and cannot bring direct financial benefits.

This year, the development of the two applications is hugely different on Ethereum. Zero-knowledge proof projects abound, and everyone is talking about them. In contrast, progress has been plodding on statelessness. Although the former started earlier than the latter, the vast difference between their status quo is astonishing. Private infrastructure is booming, especially in the hot segment; although construction of public infrastructure is continuing, the decisions are political and utilitarian. (Note: Here, “utilitarian” does not mean people are pursuing financial gains. It means doing simple things that deliver results quickly but whose negative impacts are not well-documented.)

Bitcoin presents a different picture. First, zero-knowledge proof and statelessness are treated equally, and statelessness is even more widely used than zero-knowledge proof; second, zero-knowledge proofs are used in a wider range of applications, except for those that can be financed. The construction of public infrastructure is being steadily pushed forward, and cryptography is being used as a tool rather than an end in itself.

Blockchain is sometimes likened to roads. If we follow this analogy, Ethereum is contracting out the construction of roads to private developers, who develop their own roads or facilities to expand the road system and generate revenues through tolls. The primary purpose of the construction of Ethereum’s public infrastructure is to assist and coordinate the projects of the private developers so that they can efficiently connect to and operate the central system.

But for Bitcoin, the design and construction of the main system itself account for a large part, and even private developers are mostly engaged in projects that can be used as public infrastructure.

There are two main reasons for this difference. From a technical perspective, Ethereum and Bitcoin have chosen different technical routes in terms of scaling solutions. Ethereum adopted a chain structure, which needs to increase capacity by developing sidechains. Bitcoin adopted a net structure which is easy to expand nodes in the future, what matters most is what the UTXO model and net structure can do.

There are also cultural reasons. For Bitcoin, the most important thing is “Bitcoin”, which can somewhat hamper private infrastructure involvement. But for Ethereum, the top priority is “making profits”, which will disturb the construction of public infrastructure. Different community cultures lead to different developer options, as well as different attitudes of users and investors. These options and attitudes, in turn, influence community cultures, further reinforcing certain trends.

For my part, when investigating a Bitcoin project, whether it’s related to its infrastructure or application, the first question coming to my mind is: Will it “hurt” or “boost” Bitcoin? If the answer is the former, I won’t waste my time on it. But for an Ethereum project, I’ll consider if it’s worthwhile to invest time and money in it. In other words, can I make money from these projects?

Private infrastructure is the driving force behind the industry’s growth, and public infrastructure lays the foundation for the industry’s existence. But I can’t pretend to be naive and conclude this section by saying I wish both could be taken into account—some ideas that are hard to hold on to, others that are seductive and addictive.

In the opening section of the Bitcoin white paper, Satoshi Nakamoto wrote: “While the system works well enough for most transactions, it still suffers from the inherent weaknesses of the trust based model”. In the concluding part, Satoshi wrote: “We have proposed a system for electronic transactions without relying on trust.”

From the beginning to the end, the author has argued against the trust based model and proposed a system without relying on trust. The white paper didn’t mention decentralization. It did cite the central authority as an example, simply because it is the most common object of trust in the trust based model.

Look at another white paper: Ethereum: A Next-Generation Smart Contract and Decentralized Application Platform. “Decentralized” is a frequently used word in this white paper. Its goal is to achieve “decentralization” in various situations, and even Bitcoin is treated as a decentralized rather than a trustless system.

Although they are similar at first glance, trustlessness and decentralization are different. Trustlessness can be achieved by multiple methods, including the decentralized consensus, but not any decentralized consensus can guarantee trustlessness because various factors are involved, including consensus mechanism and participants. It could even be argued that centralization can’t be trustless, and rarely can decentralization be trustless.

Different philosophy of Bitcoin and Ethereum has led to diverging development paths. Bitcoin turns to cryptography because cryptographic proof, which only relies on security assumptions, is the best way to achieve trustlessness. However, Ethereum turns to consensus, which can achieve decentralization easily.

Therefore, when we look at Bitcoin, we see a general signature, behind which all the effort and mystery are hidden; but when we look at Ethereum, we see a giant made up of multiple layers of consensus, each of which is a wealth code.

Remarks
I’d like to conclude this article with a quote from The Garden of Forking Paths. As a practitioner in  the cryptocurrency industry, I don’t want to tell which is better, and I wish them both success. If I must convey my personal opinion in this article, it would be: Please don’t try to turn Bitcoin into another Ethereum, because trustlessness is valuable, and privacy is valuable.

“With slow precision, he read two versions of the same epic chapter. In the first, an army marches into battle over a desolate mountain pass. The bleak and somber aspect of the rocky landscape made the soldiers feel that life itself was of little value, and so they won the battle easily. In the second, the same army passes through a palace where a banquet is in progress. The splendor of the feast remained a memory throughout the glorious battle, and so victory followed.”

During this bear market cycle, many are deeply involved in DeFi, while others are once again faced with a question, “What else can blockchain be used for?” People ask this not out of dissatisfaction, but because the current blockchain is like a dragon with only one wing, trapped in a limited territory. Only when its other wing grows can it soar, and the power of the first wing can truly be unleashed.

Where will the other wing grow from? It won't come from the level of chains, such as new main chains or layers; these are the dragon's torso, not its wings. It will come from the level of applications, and most likely from applications under new standards/protocols rather than old ones. Given everyone's brainstorming and innovation over the past few years, old protocols haven't brought any surprises.

In this article, I want to discuss my top three favorite new standards/protocols: ERC-6551, ERC-5169, and ERC-404. New protocols will open up new applications, and new applications may bring users to the blockchain with non-investment and non-financial needs, allowing the dragon to grow its other wing.

ERC-6551 may not have a striking appearance, but it offers a vast narrative space. This article only explores the direction that personally interests me, which I call 'non-human account entities.' The three use cases in the article may appear to be imaginary, but consider this: the destination of the aerospace industry is the vast cosmos, but before taking us to Mars, it can bring us air-cushioned shoes.

1.Gaming: The Integration of Real Players and NPCs

“Kenshi” is an open-ended game I enjoy. Players can trade goods between different cities to earn money, but the desert between cities is dangerous. In such situations, players can go to a tavern, hire mercenaries, and pay NPCs to escort the caravan. In traditional games, these NPCs cannot be real people. Because they are not real people, everything in the game, except the players, has no growth potential. Eventually, the players will complete all tasks and leave the game.

What if there was a new type of entity or object that could both embody real people and NPCs? When a real person logs in, they enter real player mode, and the player operates normally, such as improving skills and building cities. When a real person logs out, they enter NPC mode (reading fixed data and executing specific programs), passively earning money as an NPC in the real player mode of other players, such as when hired as a mercenary. The combination of blockchain and ERC-6551 could serve as the best carrier for this type of entity. NFTs (game characters) have accounts, data, and property, allowing them to be treated as independent objects. Real player accounts have NFTs, enabling them to take control when they log in.

It doesn’t mean blockchain and ERC-6551 solve all the problems related to the integration of real players and NPCs, but they open up a possible path. As a hardcore gamer, I often ask myself, “Can blockchain make games more fun?” I have listed numerous answers and, after deduction, crossed out almost all of them. Finding a path in NPCs is an answer that has not been crossed out.

2.AI: Equality Between AI and Humans

Humans are a species with amour-propre（a term used by Rousseau). We see everything as our tools or appendages. However, technology is not a human appendage. When we look at the technology tree, we find it to be another powerful force of evolution, with its own destination. If amour-propre only caused humans to miss out on a certain, more happy way of life (Levi Strauss) in the past , in the future, it may bring about a tragedy for the race.

Perhaps we need to take a step forward and consider AI as an entity equal to humans. So, where is the habitat for AI? Will they place themselves on a private server controlled by others? How should they manage and use their assets? The answer might be: a blockchain (or a consensus mechanism) where entities exist, these entities have accounts (ERC-6551), rather than accounts holding entities.

Stepping back a bit, AI game characters (especially those based on reinforcement learning) and AI agents (mass adoption narratives) are entities that need to have accounts.

3.Digitization: A Digital Version of Yourself

With data collection and AI training, generating a somewhat similar version of oneself in the digital space is no longer a distant possibility. The question lies in whether it is one in a million similar or whether it can be considered a digital version of oneself. Considering humanity's pursuit of immortality, training a digital avatar would be an ordinary thing, allowing this digital representation to persist and eventually giving it a physical body once the technology matures.

The maintenance of the “life” of this digital avatar is a challenge, especially after the prototype passes away. Entrusting it to others, including family, is unreliable due to the extended time frames involved. The best strategy is to provide it with sufficient funds to sustain itself. In this case, it needs a permanent account (an account that cannot be closed) and assets that it can autonomously manage. What solutions can you think of? Furthermore, if this digital avatar can be considered a digital version of oneself, an entity equal to humans, earning and spending money, not only sustaining but also developing itself, where does it reside? How can it achieve independence, or in other words, how can the digital avatar have ultimate control over itself?

ERC-6551 is one answer. It is a vessel for independent digital entities, whether that entity is a game character, an independent AI, or a person's digital avatar.”

Before discussing ERC-5169, we need to address two constraints that we impose on ourselves. One restraint pertains to data, and the other to trust.

Blockchain can only handle on-chain data, whose boundary is considered the upper limit of blockchain capabilities. To expand this boundary, we attempt “data on-chaining” in almost every development cycle. However, both theory and practice tell us that only a few categories of data have value or meaning on-chain. “Data on-chaining” does not effectively expand the boundaries of blockchain. We stopped here. However, there is a vast space between data that absolutely needs to be processed by the blockchain and data that doesn't need blockchain processing at all. Applications on this space can have some of their data processed by the blockchain to leverage its capabilities, while the other part of their data can be processed off-chain to gain advantages in handling data off-chain. The boundaries of this space are the upper-limits of blockchain capabilities, and this space should be included within the realm of blockchain, not excluded.

Trustlessness may be the greatest allure of blockchain, but achieving trustlessness is a challenging task. We often deceive ourselves, equating decentralization with trustlessness. Some forms of decentralization indeed bring about trustlessness, but others bring about responsible entities which invade their own responsibilities. In reality, similar to on-chain and off-chain data, some things require trustlessness, other othings require centralized trust, still others need trustlessness to safeguard rights in some parts, and centralized trust or other forms of trust to protect the rights of other parts.. The pursuit of complete trustlessness not only leads the blockchain industry to lose a significant portion of territory (combining trustlessness with other forms of trust) but also damages the interests of project participants in practice, as decentralization becomes an alternative to trustlessness.

The goal of ERC-5169 is to open up these two new territories. With this standard, developers can explore applications where some data is processed on-chain and some off-chain. They can explore applications where rights are safeguarded by a combination of trustlessness and other forms of trust. These directions are both novel and vast.

ERC-5169 is token-centric programming, meaning both on-chain and off-chain data, trustlessness and other forms of trust are anchored to a particular token. People in the Web2 world might not understand why this approach is necessary; in their eyes, a token might only be a digital asset with a face value. However, those deeply involved in the blockchain space understand the interoperability and composability that this approach brings—a revolutionary innovation in blockchain. ERC-5169 extends this innovation from on-chain data to off-chain data, from trustlessness to other forms of trust.

A good friend of mine convinced me to pay attention to ERC-404 (the standard, not a specific project) with a simple statement: “Trading blind boxes won't last; but trading wine will.” Using ERC-721 can produce products similar to “blind boxes”, while using ERC-404 can produce products similar to “wine”, and that's the beauty of ERC-404.

In terms of product attributes, the difference between “wine” and “blind boxes” lies in the fact that wine is produced in a standardized and sustainable manner. In terms of speculative attributes, the scarcity of “wine” comes from the consensus (while blind boxes’ scarcity comes from the project's setting), such as the 1982 Lafite Rothschild is the most valuable. We can consider ERC-404 as a product production machine where the input is data (production materials), such as block height, random numbers, and the output is a product that can be sold or used, such as generative art. We don’t need to intervene in the production process, because it is a standardized, automated production; we don’t need to define scarcity, because the public decides scarcity.

Illustrating ERC-404 with blind boxes and wine is simply because they are the most intuitive and easily accepted products by blockchain users. The implication behind this example is that only when a type of product can be produced in a standardized manner, can it potentially be widely adopted; only when scarcity comes from consensus can it be sustained. That’s why my friend is interested in ERC-404. He sees Web3.0 as a new type of economic activity, and he observes and judges Web3.0 projects based on what productivity is and what products are. This is a grand narrative that encompasses blockchain but goes beyond blockchain.

While ERC-404 is technically clear and understandable, the real challenge is how to use it. If the applications of ERC-6551 are mostly about creating new demands and ERC-5169's applications are about providing new solutions to real-world problems, in my view, successful applications of ERC-404 might require a mix of clever tricks and wicked craft, which can bring out the magic of ERC-404; it also requires genuine product capabilities, as forming consensus is not a simple task.

Remarks:
New standards/protocols bring new forces, and new technologies and scenarios create additional new conditions for unleashing this force. Taking ERC-6551 as an example, it can be combined with many new technologies, including intent-centric and account abstraction. It can be applied to various new scenarios, such as autonomous worlds and AI.

Finally, when we discuss the value of various new standards/protocols, it does not mean that the directly related projects have value. It means that based on these new protocols, new plays or new projects will emerge, and these new plays or new projects may break the deadlock, like the dragon growing wings.