Permaswap recently released an AgentFi demo case based on FusionFi Protocol (FFP) on AO, adding a case of creating an automated market maker agent (AMM Agent) and performing arbitrage operations. Through FFP, developers can create AMM agent pools with just a few lines of code to achieve asset exchange. As a standardized protocol on the AO network, FFP provides interoperability support for different types of Agents.

This article will first clarify core concepts such as AgentFi and sovereign finance, then introduce two typical Agent examples - Orderbook Agent and AMM Agent. It will demonstrate how the FFP protocol integrates two different trading processes. Finally, we will explain the key role that FFP can play in the future financial ecosystems.

Basic Concepts

AgentFi introduces the concept of "agents" on top of DeFi, allowing users to deploy their own smart contract agents to automatically manage interactions with protocols. Through Agent, users can autonomously execute various financial operations, such as asset management and strategy execution.

Traditional DeFi protocols use smart contracts to implement operations like asset exchange and lending, but these assets are usually locked in a single smart contract. This requires users to entrust their funds to the contract and also limits their flexibility in customizing desired functions and parameters. AgentFi breaks through this limitation. It enables each user to have an independent agent with financial capabilities, then the users can use their agents to conduct personalized financial business. In other words, AgentFi makes users' agents independent financial entities, allowing individuals to set financial rules, such as asset exchange, lending, and asset issuance rules. It helps achieve personalized financial management and break through the limitations of traditional centralization.

This is Sovereign Finance!

Unlike traditional centralized systems where financial rules are controlled by central banks, sovereign finance allows users to establish and control financial rules themselves. They no longer need to rely on smart contracts provided by developers or centralized institutions.

The Foundation of AgentFi: Performance and Flexibility

One of the reasons why traditional DeFi protocols centrally manage funds is due to the limitations of Ethereum's performance: it cannot provide independent agent’s computing power for each user. Therefore, platforms like Compound and Uniswap have optimized their code to accommodate the limitations of the blockchain. Additionally, traditional blockchain smart contracts have low flexibility and are difficult to modify or redeploy, which limits the agents’ computational flexibility.

AO, as a decentralized global hyper parallel computer, provides independent computing units (called processes). Each process has its own computing resources, which helps resolve the performance bottleneck. Meanwhile, the smart contract code running in the processes is controlled by the process owners and can be flexibly updated and upgraded, providing a solid foundation for the flexibility of AgentFi.

FusionFi Protocol

In AO's decentralized network, AgentFi will be widely adopted. Applications can generate multiple independent financial entities. For example, NPCs in games not only provide gaming services but also financial services. For instance, a pawnshop NPC can accept players' NFTs as collateral and provide lending services, making this NPC an independent Agent, i.e., a sovereign financial entity. All users and processes on AO can create financial agents in this way, and any computing unit can become a "financial institution" providing customized financial services.

If different types of financial agents develop independently, they will inevitably produce different protocol standards, making interaction between agents a major challenge. To address the interoperability issues caused by business differences, the FusionFi Protocol (FFP) was born.

FusionFi Protocol is a specification and development tool designed to connect different financial agents, establish information channels, achieve interoperability, and integrate diverse financial operations. It enables FFP-compatible Agents to interconnect and communicate.

For users who are not interested in delving into financial details, they can also use the FFP SDK to convert their agents into agents with specific financial features. By reducing the implementation difficulty of AgentFi, FFP makes sovereign finance accessible to everyone.

Use Case and Interoperability

Order Book and AMM (Automated Market Maker) are two different trading mechanisms with significant differences in their trading processes. Order Book records all buy and sell intentions, and trades can only be executed when the prices of buyers and sellers match, thus relying on the participation of counterparties. AMM, on the other hand, does not rely on counterparties. It allows users to trade directly with assets in the pool through liquidity pools and algorithms. Liquidity providers deposit funds into the pool, and AMM uses algorithms (such as constant product formula) to automatically adjust prices, enabling users to complete transactions without waiting for matching.

FFP can handle Orderbook and AMM transactions in a unified manner and process, thereby integrating the liquidity of both.

Please refer to the demo code: https://github.com/permadao/ffp-demo

Orderbook Agent

In the orderbook demo of FFP, developers can create an Orderbook Agent and conduct asset trading:

1. Create Orderbook Agent: Use the createOrderbookProcess function to create an orderbook agent process, which deploys an AO process and loads “orderbook” related business code, making it an independent financial entity responsible for recording and managing orders.

2. Deposit assets: Use the deposit.js script to deposit tokens into the orderbook agent to provide trading funds for orders.

3. Create orders: Use the agent.makeOrder method to create buy or sell orders in the orderbook. All orders are sent to the AO network in a specific FFP Schema, after which the orders will be transparently displayed in a specific format on the blockchain network and await matching.

4. Take orders: Use the agent.takeOrder method to take orders, and the system automatically completes the transaction and updates the asset balance.

AMM Agent

In the demo of AMM Agent, the Agent created by the user is equivalent to a personal sovereign liquidity pool. Through AgentFi, users can autonomously provide asset exchange functions without relying on centralized platforms or traditional exchanges. The following is the core process of AMM Agent:

1. Create AMM Agent: Create an AMM Agent process through the createAMMProcess function, and deploy it as a user-controlled AO process, making it a sovereign financial entity with liquidity management capabilities.

2. Deposit Assets: Users deposit tokens into the AMM Agent, injecting funds into the liquidity pool.

3. Add Liquidity: By calling the agent.addLiquidity method, the deposited assets can be added to the liquidity pool, and users can set the pricing and exchange ratio of the assets in the pool through smart contracts.

4. Automatic Exchange: The AMM Agent uses algorithms (such as the constant product formula) to automatically calculate the exchange rate. The quote results are returned to the user requesting the transaction in a specific FFP Schema.

5. Remove Liquidity: When users want to withdraw funds, they can use the agent.removeLiquidity method to remove liquidity from the pool and withdraw assets.

By creating an AMM Agent, users have full autonomy over liquidity management and can provide asset exchange services without counterparties, thereby establishing a personalized decentralized trading system.

It can be considered that when a user creates an Agent (whether an AMM Agent or an Orderbook Agent), they are essentially creating a personal sovereign decentralized exchange. AgentFi completely breaks the traditional boundaries of exchanges, it allows users to trade without relying on a specific platform. By setting up Agents with specific functions and smart contract rules, users can autonomously provide a "venue" for exchanges, and achieve sovereign financial services. All it takes is just one line of code to create an agent.

Interoperability

FFP Schema is a data format used in FusionFi Protocol (FFP) for standardizing transaction and settlement data. It defines the data format and communication protocol in different trading processes (such as Orderbook and AMM), ensuring smooth interoperability and compatibility between different types of financial agents. This unified data format allows key info such as prices, order status, and asset information to be shared and parsed among various agents during the trading process.

In the fourth step of the Orderbook Agent and AMM Agent, both Orderbook orders and AMM requests adopt a unified FFP Schema to achieve a consistent settlement data format. The FFP Schema standardizes cross-agent interoperability:

• Arbitrageurs can directly query Orderbook orders on-chain, comparing quotes between Orderbook and AMM using the FFP Schema to discover price differences.

• Arbitrageurs only need to submit uniformly formatted transaction data to the FFP settlement process to achieve atomic transactions across Agents. The FFP specification ensures that multiple hedging orders are either all completed or all failed, avoiding the risk of transaction inconsistency.

In the above use cases, the different trading processes of Orderbook and AMM achieve interoperability. FFP breaks the boundaries between the two types of businesses, achieving collaboration and integration between them.

Advanced Features

FFP supports atomic settlement of multiple transactions and provides the following advanced features for DEXs built on FFP:

• Large Order Splitting: Traders can split large orders into multiple smaller orders. For example, a trader needs to complete a $1 million transaction, but a single Agent may find it difficult to provide the best quote. FFP allows large orders to be split into multiple smaller ones, executed among different Agents to obtain the best quotes in the network.

• Multiple Orders Merging: Scattered orders in the market can be merged into a single atomic order, enhancing the interoperability of the Orderbook and AMM, and making transactions more flexible.

• Multi-hop Trading: Multi-hop trading is an extended application of the merging function. For example, if a trader wants to exchange asset A for C, but there is no A-C trading pair in the market, yet there are A-B and B-C trading pairs, FFP can merge the A-B and B-C transactions into one order to achieve the trading goal.

• Zero-Capital Arbitrage: Arbitrageurs can profit from the price difference between two hedging orders in the market. Unlike traditional arbitrage methods, FFP's zero-capital arbitrage doesn't require self-owned funds. Arbitrageurs only need to submit the two orders to the settlement process, and the system will automatically complete the asset exchange and distribute the profit to the arbitrageur.

These innovative features brought by FFP not only simplify the trading experience for users and ensure optimal quotes, but also improve capital efficiency for arbitrageurs and guarantee the efficient circulation of value.

Vision

In summary, FFP provides a unified framework for financial agents, breaking down barriers between different financial scenarios. Not only for orderbooks and AMM, but various financial operations such as lending, futures, and synthetic assets can also be seamlessly integrated in the future through FFP. It will help build a cross-application, cross-scenario decentralized financial ecosystem.

Through a unified data format (FFP Schema), FFP simplifies communication and settlement between agents, thus enhancing the flexibility and efficiency of transactions. As more types of financial agents emerge, FFP has the potential to become the core protocol for the AgentFi ecosystem on AO, promoting the popularization of truly sovereign finance and personalized financial services.

From Permaswap Self-Custody to AgentFi

Two years ago, we designed and implemented Permaswap Network (PSN), a decentralized asset self-custody trading network. PSN is a network protocol that defines the interactions between LPs and trading users, providing a trustless mechanism for asset exchange. PSN is completely open-source, allowing anyone to review the protocol and freely join or leave the network.

In the PSN network, there are two types of nodes: Routers and LPs. Routers are responsible for aggregating information from LPs and generating many-to-many trading orders for users who need to trade. LP nodes, which include automated market-making programs, allow users to flexibly configure their LP nodes' market-making rules, such as setting up k = x * y curves to become an AMM node.

Unlike Ethereum, funds in PSN are not concentrated in a single smart contract but are self-custodied by each LP node. Nodes exchange information through a unified protocol. When a user requests the network, they can obtain a many-to-many trading order, meaning a single transaction may involve asset exchanges with several or even dozens of LPs simultaneously. Each order must be signed by all trading parties to be settled. If any signature is missing or any party fails to make the payment as per the order, the transaction will fail.

This self-custody LP model can be considered a prototype of what we now refer to as AgentFi on AO. One major difference is that users in the PSN network need to run their own nodes to participate in the network, whereas, in AO's AgentFi, the node programs are abstracted into processes on the AO computer. This means users do not need to run programs locally but can use the trustless AO computer to run their agent programs.

From AgentFi to Intelligent Finance

Traditional DeFi, due to the performance limitations of public chain smart contracts, requires liquidity providers to deposit assets into specified contracts to conduct financial activities. AO and the agent model will change this situation. On AO, users can launch their own processes, which are essentially user-managed smart contracts with distributed and trustless operation characteristics. The creation and use costs of these processes are much lower than those of Ethereum and other public chain smart contracts. Users' assets are automatically managed by their own processes, and each process acts as an intelligent agent robot that can be programmed to manage the user's assets automatically.

Traditional blockchain smart contracts are difficult to modify and upgrade, and usually, assets are managed within a single unified smart contract. For example, Uniswap uses the k = x * y curve to manage asset exchanges uniformly, and Compound adopts a unified interest rate model to manage lending. Traditional smart contracts use a single strategy to manage large amounts of assets, which is not very "intelligent." Through AO, users can manage assets using personal processes, modifying the process code and configuring various strategies at any time, providing much higher flexibility.

Transitioning from centralized management to decentralized intelligent management, AO processes will make asset management more efficient and intelligent.

Additionally, agent robots are very easy to integrate with AI. The strategies of agent robots can be updated by AI, and AI can also provide oracle services for the agent robots, adjusting or modifying strategies based on external data. Currently, large language models have been successfully tested and run on AO. In the near future, agent finance may be fully managed by AI, operating 24/7 to continuously generate profits, thus realizing intelligent finance.

Moreover, Unifying Finance’s model

Our exploration does not stop here.

In ancient times, bartering was common. Bookkeeping became a more convenient way of trading, allowing the exchange of value without the immediate transfer of physical goods. This significantly boosted the rate of value exchange, leading to more efficient division of labor and increased productivity. Along with this, the demand for flexible and convenient transactions grew. From bookkeeping, notes (promissory notes) gradually emerged. Notes are powerful tools that can record debt transfers, payments, transfers, and financing in various financial scenarios. Checks, a common type of note, offer a convenient and secure method of payment. Today, many payments are made through electronic means, but their essence remains credit, and notes are crucial for recording credit and transferring value. Essentially, all financial activities revolve around notes, either directly using them for value exchange or utilizing their variants.

When designing financial products in traditional finance, designers need to consider the trust issues between different financial entities. These issues are addressed through regulation and legal frameworks, requiring significant effort to ensure compliance and manage trust among various parties. However, in the world of blockchain and other trustless protocols, these concerns simply do not exist. Developers have created diverse DeFi financial ecosystems on trustless platforms like Ethereum. As blockchain technology matures, we can leverage the more powerful AO computer and continue to restructure the financial industry using the concept of AgentFi.

Traditional financial instruments include various types of notes, such as promissory notes, bills of exchange, checks, and discounted notes. The existence of these different types is due to varying trust requirements among different entities, necessitating different legal and compliance measures. However, in a world without trust issues, this proliferation of financial instruments simplifies down to their core abstraction: the financial note. We can use the note as a prototype to implement any financial mechanism. This led to the creation of AgentFi notes, which are incredibly powerful and can express almost any financial business.

AgentFi notes also signify a change in financial sovereignty. The trust issues of traditional notes meant that finance could only be a tool for authoritative institutions and sovereign states. The emergence of DeFi marked a shift from government sovereignty to code sovereignty in finance. AgentFi notes will hand financial rights to individuals, allowing anyone to issue their own notes and assets, defining personal sovereign financial instruments and behaviors.

Using AgentFi notes, we can unify finance by modeling any financial instrument. Let's take a look at example of how AgentFi notes improve outcomes.

Exchange

Suppose Alice and Bob are the two counterparties in a transaction. Alice requests an exchange rate from Bob, and Bob informs Alice that the rate is P1. If Alice considers P1 reasonable, she will choose to proceed with the transaction; otherwise, she will cancel it.

Even if Alice agrees to P1, Bob may still refuse the transaction since it hasn't been settled. If Alice wants to proceed but Bob refuses, Bob's quote is considered invalid. We view Bob's invalid quote as malicious because Alice loses the opportunity to request other quotes while waiting for Bob's response. In this process, Bob could consistently provide the best quote in the market but never complete the transaction.

To prevent Bob from making malicious quotes, we require the quoting counterparty to provide a note with collateral.

Using Permaswap's token $HALO as an example, Alice requests a quote from Bob for an exchange amount of $100. Bob returns a note collateralized with 10 $HALO (equivalent to $1). The note is valid for a very short period, possibly only 10 seconds. If Alice agrees to the price within 10 seconds, she can initiate the settlement function via a smart contract. At this point, the tokens from both parties are exchanged atomically. Once the settlement is completed, the 10 $HALO collateral is returned to Bob. If Bob refuses to settle, his 10 $HALO collateral will be forfeited and transferred to Alice.

By combining AgentFi notes with the settlement capabilities of smart contracts, we can make the exchange process more resistant to bad actors. Whether using AMM or orderbook decentralized trading models, notes can be used to establish trust between different counterparties.

Futures

In the exchange scenario, the note's expiration time is only 10 seconds. If we provide a longer-term note with a specific settlement time, this note can serve as a futures certificate.

Bob creates a note for an asset currently valued at $100, with a settlement time of one week later. This note is collateralized with more $HALO, with only 1% collateral in the exchange scenario. In the futures scenario, Bob, as the issuer, needs to provide collateral equal to 20% of the note's current value. Additionally, the note requires the holder to also collateralize 20% of the asset.

Alice collateralizes the required amount and becomes the holder, activating the note. One week later, if the asset's value rises from $100 to $115, Alice can initiate a settlement and receive the $115 worth of the asset. If Bob refuses to deliver the asset, the 20% $HALO collateral will be forfeited and given to Alice.

If the asset's value drops from $100 to $90, Bob can initiate the settlement. Bob will still receive $100, and if Alice refuses to deliver the asset, the 20% $HALO collateralized by Alice will be forfeited and given to Bob.

Collateralized Lending

Similarly, for a long-term note, the expiration time could be one year, and it would include an interest function.

Bob, holding a large amount of $HALO, wants to use it as collateral to borrow from Alice. Bob provides a note with a one-year term, collateralized with 1,000 $HALO (worth $100). The note is valued at $80 and offers an additional 5% annual interest for settlement. Alice pays $80 to purchase the note, and Bob receives an $80 loan.

During the one-year term, as long as the value of 1,000 $HALO remains above $100, Bob can initiate a settlement upon the note's maturity. With a 5% annual interest, Bob needs to pay $80 * (1 + 5%) = $84 to settle the note. After settlement, Bob retrieves the 1,000 $HALO, and Alice receives $84.

If within the one-year term the value of 1,000 $HALO is about to drop below $84 (not $80 because interest is included), for example, at $85, anyone can initiate a settlement. After settlement, Bob will lose all his $HALO, Alice will receive $84, and the settler will get the difference of $85 - $84 from selling 1,000 $HALO, which is a $1 reward for the settler.

Currency

There is a close relationship between notes and currency.

Bob can over-collateralize $HALO and issue a note with a value of $1. This note is equivalent to currency, akin to a stablecoin, and can be circulated and used as a stable medium of exchange in the market.

Realizing the Unified Financial Protocol of Permaweb

Finance has undergone significant development over the past millennia, especially in the last two hundred years, to keep pace with industrialization and information technology. The financial industry has given rise to many different business types and directions. The emergence of blockchain technology will change all this. By solving the trust issues associated with ledgers, the construction of all financial services becomes much simpler. We have revealed the uniformity of finance, allowing us to simplify and reconstruct complex financial services, ultimately achieving Fusion Finance.

From the self-custody network of Permaswap to AO's AgentFi, blockchain technology has made significant strides. Permaswap will continue to evolve with technological advancements, realizing a complete and unified financial protocol on the Permaweb.

Summary

PermaDAO is exploring the practical transition from traditional “human governance” to fully "On-Chain Governance." With Bitcoin and Ethereum communities serving as examples, Decentralized Autonomous Organizations (DAOs) are flourishing with the support of blockchain technology. While DAO's have excelled in creating simple rules, navigating collaborations entailing intricate regulations remains a complex challenge. The ultimate goal for DAOs is fully on-chain governance, a realization that requires a prolonged evolutionary process. PermaDAO, recognizing this, will release the HALO governance token, progressively advancing towards a fully on-chain governance model through "meta-governance concept.”

A Decentralized Autonomous Organization (DAO) is a form of organizational structure embodied through open-source code, controlled by shareholders, and impervious to the influence of central authorities. Due to the immutable and traceable blockchain smart contracts features, DAOs have received robust technical support and have made significant strides in cryptography.

The Bitcoin and Ethereum communities represent DAOs, where consensus is formed through code, fostering community collaboration to enhance the system for common goals. DAOs have made significant strides in decentralized community governance, primarily due to the relatively simple Bitcoin and Ethereum rules. The fundamental Bitcoin rules revolve around payments, essentially involving miners providing BTC payment services. Similarly, the basic Ethereum rules entails miners to provide smart contract computing services.

Additionally, Uniswap, with its simple formula of k = x * y, offers decentralized asset swaps, representing a fundamental rule for DAOs. Built upon this formula, Uniswap serves a vast user base, liquidity providers, and arbitrageurs, creating a token exchange ecosystem that is open to all, allowing participants to join or exit at any time.

It is evident that DAOs have had a profound impact on collaborative efforts based on simple fundamental rules, yet there have yet to be notably successful cases in collaborations involving complex rules.

Dual Aspects of Governance

Rule of man

The traditional governance model, often referred to as the "rule of man," involves individuals creating a set of rules through communication and coordination to manage production and consumption relationships. These rules are codified into laws and regulations, forming standards that can be referenced. The enforcement of laws relies on centralized violent institutions for protection.

The rule of man developed over thousands of years, has become highly mature but also intricate. Whether at the scale of a company or a nation, all the rules and laws within a system are products of human governance.

A mature human governance system can handle highly complex collaborative issues, which is a capability that current DAOs have not yet fully achieved.

Code is law

The emergence of smart contracts has sparked a new wave of governance, making it easier to manage organizations using open-source code. Smart contracts rules are executed by machines, eliminating any margin of error, avoiding informal rules and fraud that may exist in human governance.

However, due to this mechanism's precision, the flexibility is limited. If incorrect rules are established (often referred to as smart contract vulnerability), the losses caused by these vulnerabilities can be challenging to recover. The DAO incident on Ethereum in 2016 is an example where significant asset losses occurred due to a smart contract vulnerability. Ultimately, this led to a division within the Ethereum community. The outcome was a rollback from "code is law" to “rule of man". Guided by Vitalik, the community refused to acknowledge the results created and ultimately decided to roll back the blockchain to its state before the theft occurred.

At the end of the day, the lack of flexibility restricted "the rule of code" to small-scale applications and scenarios with relatively simple foundational rules.

Opposing Forces?

The dual sides of governance, the “rule of man" and “code is law” seem to have conflict and opposition. With the recurring security incidents and governance failures, does this imply that DAOs are destined to struggle with complex collaborations. Are DAOs a utopian fantasy?

Making DAOs applicable to complex collaboration rules, suitable for large-scale collaborations involving strangers, is the direction PermaDAO is looking at.

Indeed, the “rule of man" and “code is law" are not opposing forces. Whether it's rules computed by machines or legal rules documented in books, humans remain to be the core of collaboration. DAO Practitioners don’t need to bring all actions under blockchain governance; instead, they should start with a human-based input and gradually introduce on-chain rules. The rules computed by machines aim to minimize the trust costs between individuals and reduce the consensus cost of value distribution (cutting the need for violent enforcement), rules executed by machines are more efficient and transparent, enabling human governance to achieve faster iterations and stronger execution capabilities.

In the process of PermaDAO's practice, there hasn't been an excessive pursuit of fully on-chain governance. Early on, it was driven by individual enthusiasts, gradually establishing rules, expanding the community membership, and constructing bit by bit. The following two cases might indicate an excessive reliance on on-chain governance:

1. PandaDAO. Excessive reliance on on-chain governance, token issuance, and NFT distribution, coupled with a lack of efficient decision-making and rational contributors, ultimately led to a downward spiral.

2. Polkadot. Despite establishing complex on-chain governance mechanisms upon launching, allowing all functionalities to be improved through voting, it ultimately failed to yield truly effective applications. The lesson learned is not to become excessively absorbed in on-chain governance prematurely; instead, growth should occur organically based on the needs of users and developers.

The typical manifestation of excessive on-chain governance is engaging in extensive discussions about governance and advantages even before the community has formed. This is often accomplished by creating FOMO sentiments through methods like token issuance or prematurely using NFTs as a medium for user acquisition, resulting in the unhealthy rapid growth of the community. In the end, all participants are fixed within a carefully designed behavioral pattern, unable to change anything or determine the future direction of the DAO. Embracing fully on-chain governance from the outset is not a favorable governance path. Even in mature and large ecosystems like the Bitcoin and Ethereum communities, full on-chain governance has not truly been initiated. Instead, communication, management, and iterative growth are more often facilitated through human-centric community models. The Bitcoin community grew slowly rather than being designed. It started with just a few enthusiasts running Bitcoin code on personal computers, then progressed to someone buying pizza with Bitcoin, and eventually evolved into the massive computational power we see today. The governance and development process of DAOs is both lengthy and challenging.

Meta-Governance

In stark contrast to the previously mentioned excessive on-chain governance, Meta-Governance has minimal pre-defined rules. First and foremost, there is no genuinely orchestrated set of rules by an official entity to entice more people to join and generate FOMO. Secondly, Meta-Governance places more emphasis on how the governance process is generated. It adopts a human-centric governance model, relying on contributors to create rules.

The PermaDAO theme revolves around the Arweave ecosystem, with a core philosophy of exploring large-scale collaboration amongst strangers. All rules only need to expand around these two aspects. We hope any contributor can create rules, introduce new types of work, and generate more tasks. Of course, the premise is that these rules and tasks can operate clearly, and the execution results can be recorded on the blockchain. Permanence is also a crucial foundation feature for PermaDAO. The process of everyone's contributions will ultimately be recorded on the blockchain, creating a permanent record. Your workload will forever belong to you, thanks to Arweave’s permanent storage.

In practice, through Meta-Governance, PermaDAO generates autonomous domains such as Activity Guild, Content Guild, Branding Guild, Development Guild, and more. The rules of these guilds are created spontaneously by contributors in the community. Initially, many guilds faced various issues, but as more contributors joined, there were always individuals raising questions and finding solutions.

Occasionally, contributors would inquire why PermaDAO hasn't issued NFTs to attract newcomers. According to the Meta-Governance logic, the issuance of NFTs is also a rule created by contributors. There won't be corresponding rules until community members propose and promote such proposals within the community.

The governance of DAO relies on the community itself, not on any so-called official entity. Meta-governance is the process of creating rules amidst chaos, evolving from disorder to order in an automated manner.

Fully On-Chain Governance

Excessive on-chain governance is not a good practice, but fully on-chain governance remains the ultimate goal that DAOs explore, it just needs a more lengthy evolutionary process to achieve it eventually. The rules of on-chain governance should not be prematurely defined. Due to the lack of flexibility in smart contract code, early definitions can lead to the model having issues and ultimately creating a death spiral to failure. After all, it hasn’t even been a decade since DAO exploration started, and there are too many issues to explore and solve. We hope to start with Meta-Governance, deriving a model of full on-chain governance from chaos, without expecting to produce a FOMO model meticulously designed by a few individuals but still flawed.

Exploring HALO Token

PermaDAO has been using the approach of Meta-Governance in its exploration of DAO for over a year. There are over 1000 articles created and translated within the DAO, and more than 10,000 tasks of various types have been executed. These tasks include, but are not limited to, Space activities, large-scale offline events, PR campaigns, software development, content creation, content translation, financial settlements, and institutional proposals. PermaDAO's currently has 370 contributors, achieving the collaboration scale of a medium-sized enterprise through 100% online cooperation. Over 50 active contributors receive AR incentives weekly. The achievements are significant!

With the guild rules made now being mature, the DAO is poised to embark on the next phase of exploration—how to achieve fully on-chain governance! In the three stages of DAO development, pioneers delve into rule exploration when talent is scarce. After establishing rules, in the mid-term, more contributors are attracted, and a fair and transparent promotion system is instituted, fostering healthy and sustainable development. Ultimately, this leads to the exploration of fully on-chain governance.

We introduced the HALO Token for governance voting. With HALO allocation based on past workload data. All contributors will receive HALO tokens, with the quantity tied to their past workload to encourage and recognize volunteers' contributions. Initially distributed HALO will be in a locked state, granting voting and governance rights, with weight proportional to workload time. This approach respects early contributors, safeguarding their interests as they played a crucial role in the DAO's early stages when talent was scarce.

The HALO Token obtained through contributions to different guilds carries different voting characteristics. The HALO Token from that particular guild weighed ten times more than the HALO voted to other guilds. This measure is designed to safeguard the governance rights of guild professionals and prevent the rules established by a guild's founders from being easily overturned.

Staked HALO can be unstaked and traded on secondary markets, but unstaking sadly means that you’ll be forfeiting your voting rights. In a permissionless DAO, new members must contribute by working or repurchasing HALO to gain voting rights. HALO purchased on the secondary market after locking won't inherit the tenfold voting weight.

Conclusion

In the governance realm, decisions, both centralized and decentralized acknowledge the pivotal role played by individuals. In the age of information and blockchain, a unique opportunity presents itself — the creation of a platform that manifests fair and transparent visions, granting greater autonomy to individuals in designing systems. The HALO Token will serve as a powerful tool for PermaDAO to explore fully on-chain governance. Despite the risks, HALO will operate as a test token before its official launch. PermaDAO is poised to execute on-chain governance voting using blockchain technology, encompassing facets such as scrutinizing guild rule proposals, electing leaders, and rotating key positions. The efficacy of meta-governance has already manifested during PermaDAO's early stages. We firmly believe that the future will witness the exploration of highly viable solutions for complete on-chain governance, establishing the groundwork for extensive collaboration among blockchain strangers.

We extend a heartfelt welcome to individuals with expertise to join PermaDAO, contribute proposals, and engage in collaborative efforts to refine rules. Within this realm, no rules are immutable; there are only opportunities for improvement. While the current framework may seem somewhat antiquated, the forces of emergence and evolution are certain to infuse a renewed brilliance into the system.

This article will provide a technical interpretation of Permaweb while incorporating SCP(Storage-based Consensus Paradigm) theory.

Framework

Permaweb follows a three-layer architecture. The top layer is the Application Layer, which is the user-facing interface. The middle layer is the Service Layer, providing backend services to the application. The bottom layer is the Storage Layer, utilizing Arweave to offer data storage services.

The architecture of Permaweb is not significantly different from Web2 architecture. The Application Layer corresponds to the frontend in traditional Web2, the Service Layer corresponds to the backend, and the Storage Layer corresponds to physical servers or databases.

The most significant distinction between Permaweb and Web2 is the use of decentralized storage. Once Permaweb applications integrate permanent storage like Arweave, tampering and erasing application content becomes very difficult, granting the application decentralized properties. Although Permaweb's architecture resembles Web2, its underlying technology and design philosophy fundamentally differ.

Permaweb's architecture is shown in the figure below (from Permaweb Cookbook: https://cookbook.arweave.asia/). The following sections will provide a detailed overview of Permaweb's three-layer architecture.

Storage Layer

The Storage Layer is the core of Permaweb. Without blockchain technology in the storage layer, there would be no difference between Permaweb and Web2. The storage layer of Permaweb is not limited to Arweave. Theoretically, Bitcoin or Ethereum could also be used as a storage layer to create a Permaweb application, but developers and users may struggle with high storage costs. Arweave, with its professional permanent storage blockchain capabilities and costing only $5 for 1 GB, is the optimal choice for being the storage layer of Permaweb.

Can the storage layer use IPFS? If IPFS is used, Permaweb will lose the data traceability feature. IPFS's data CID ensures immutability, but IPFS does not use blockchain technology. IPFS data lacks block timestamps, making it impossible to discern the time of data creation. Additionally, data will be lost if IPFS service nodes are shut down, making data permanence and traceability unassured.

Service Layer

The service layer serves as a unified middleware providing APIs to applications, similar to a Web2 microservices cluster, being stateless and capable of horizontal scaling. Typically, Permaweb's service layer offers standardized interfaces and protocols (similar to Web2's gRPC or Thrift, the entirely open-source). These interfaces and protocols are fully open-source, and any service provider that deploys services can provide the same API based on the protocol standard. As long as an application is developed using the standard protocol, it can operate and be used on different service layers.

Currently, Arweave's service layer includes four core components:

• Gateway services: Caches frequently used Arweave data. Examples include arweave.asia, arweave.dev, g8way.io, ar-io.dev, and more.

• Binding services: Using the Arweave ANS-104 standard, large amounts of data are batched and packaged onto Arweave. Examples include bundlr, arseeding, etc. Data conforming to ANS-104 can also be queried using GraphQL.

• Sequence services: Smart contract services, payment services, etc. Examples include Warp, everPay, etc.

• Indexing services: Arweave Tags retrieval service, full-text indexing service. Examples include Adot, KNN3, goldsky, etc.

Currently, the standard protocol includes only these four modules, but in the future, Permaweb's service layer could be further expanded with new standards.

Application Layer

Permaweb applications possess Serverless characteristics; developers don't need to deploy servers. As the service layer provides standard interfaces to the application layer, applications developed according to specifications can operate and be used on any service layer.

Interaction

Users only need to interact with the service layer without interacting with the underlying blockchain.

• Resource loading: A standardized gateway provides all necessary file resources that the Permaweb frontend needs to load. These file resources are organized in a directory format based on the Manifest standard, making it easy for web protocols to load and assemble them.

• Data writing: Writing to Permaweb usually employs the ANS-104 standard on Arweave, supporting large-scale data writing. The bundle service implemented using ANS-104 makes the writing experience on Permaweb consistent with Web2.

• Data querying and indexing: A standardized indexing service enables Permaweb to load content dynamically. Indexing doesn't require waiting for data to be packed onto Arweave, once data is uploaded to the bundle service, efficient application indexes can be generated in real-time, providing users with real-time data querying capabilities.

In summary, interaction-wise, Permaweb can provide an entirely consistent experience with Web2.

Resistance to Censorship

The standard protocol and interfaces provide applications with anti-censorship features. Below are URLs of a Permaweb application named "cookbook":

• https://cookbook.arweave.asia/

• https://cookbook.arweave.dev/

• https://cookbook.g8way.io/

• https://cookbook.ar-io.dev/

You can see that any of these URLs can access the "cookbook" application. This website is served by different gateways and servers globally. If arweave.asia becomes inaccessible, users can still use other URLs to continue using the application. Even if all gateways are closed, the cookbook's data is stored using Arweave, and this data won't be lost, allowing service providers to restore the "cookbook" application at any time.

Using Arweave's permanent storage as the storage layer ensures data decentralization for every Permaweb application. Adopting standardized, open-source protocols for the service layer, can prevent censorship risks caused by the closure of individual servers due to uncontrollable circumstances. Permaweb applications possess decentralized and censorship-resistant features.

Microservices Version of SCP

The architecture of Permaweb is similar to traditional Web2 architecture. Essentially, Permaweb is a set of microservices-based application architecture built on decentralized storage.

Microservices is a software architecture pattern used in Web2 development that breaks down a large and complex application into a series of smaller, more independent service units. Each microservice is an isolated functional module that can be developed, deployed, and operated independently. These microservices communicate with each other through well-defined APIs and can use lightweight communication protocols such as HTTP or message queues to achieve interoperability.

The overall architecture of Permaweb is very similar to microservices. Each Permaweb application is composed of standardized and independent service units. This same design philosophy equips Permaweb with the capability to build complex applications on a large scale.

What sets Permaweb apart from traditional microservices is its alignment with SCP, making it an SCP-based microservices architecture.

What is SCP (Storage-based Consensus Paradigm)? It's a consensus paradigm based on storage, where the core idea is that as long as the storage is immutable and transactions on it are traceable, the result of application computation will be unique anywhere, leading to consensus. A distinctive feature of SCP is that underlying data can be infinitely combinable. As long as there are standardized ways of assembling data, applications can aggregate unique states from any storage layer, even multiple storage layers together.

When developing applications using SCP, traditional application architectures require minimal adjustments. Only the database (storage layer) must be replaced with immutable and traceable blockchain storage.

Advantages

Applications developed using this decentralized microservices architecture can acquire equivalent features of blockchain technology. These features include decentralization, immutability, traceability, resistance to censorship, and more.

Similar to traditional microservices architecture, this framework offers the following development advantages:

1. Modularity and Maintainability: Independent services responsible for specific functions. This standardized and modular design allows each service to be developed, tested, deployed, and maintained independently, enhancing application maintainability and flexibility.

2. Independence: Each service can be developed and maintained by different teams, aligning with the characteristics of DAOs. This allows various organizations and individuals to contribute their best performance and development speed to Permaweb. It also enables developers to choose the most suitable technology stack and tools. In the Arweave ecosystem, we can see different teams providing various services, such as gateways offered by ar.io, data binding services provided by bundlr and the open-source arseeding, and dedicated financial services offered by everPay and Permaswap, among others.

3. Scalability: Independent services can be horizontally scaled as needed. Each service could even be likened to the shards mentioned in ETH 2.0, but Permaweb doesn't have a limitation on the number of shards and can scale infinitely horizontally. Additionally, the same protocol standard can offer different data set services. For instance, certain gateways can optimize the access speed for specific applications by caching and processing data for those applications only.

4. High Availability: With multiple available gateways (microservices), the application avoids single points of failure and achieves better availability.

This architecture inherits all the advantages of microservices while overcoming the Blockchain impossible trinity. Traditional blockchain applications had to sacrifice one feature among scalability, security, and decentralization to ensure the integrity of the other two. Under the SCP theory, due to the layered architectural design, consensus will be guaranteed by the storage layer and a universal protocol. Decentralization is no longer strongly related to the number of nodes but to the openness (open-source nature) of the protocol. When discussing Ethereum's decentralization, apart from considering the number of nodes, it's crucial to recognize that the Ethereum software itself is a standard protocol. Users and miners reach consensus using the same protocol, forming a high degree of decentralization. In the case of Ethereum, the majority of users and developers currently use services provided by infura.io. Although infura.io is a centralized service, users can deploy the Ethereum protocol at any time and independently access the network. Similarly, decentralized microservices can fulfill the mentioned characteristics. However, decentralized microservices aren't tied to a specific VM architecture (like EVM). Instead, they are more flexible and closer to the theoretical model of traditional architecture. They represent the next-generation decentralized internet architecture born from the fusion of microservices and SCP theory.

Practice: From Arweave, Beyond Arweave

Currently, Permaweb has only four services: gateway, data binding, sequence, and indexing. These services have formed a certain standard. So, what exactly is a Permaweb instance, and how is it built using these four standard services?

The "Now" Application

https://now.arweave.asia is a Permaweb application (referred to as "Now" in the following text) that serves as a platform for communication among developers within the Arweave ecosystem. The primary function of Now is to allow users to initiate blogs, and other users can like the content of these blogs.

All the data of Now is stored on Arweave, ensuring decentralization through immutable storage. When a user opens Now, the browser loads a frontend framework from Arweave's gateway service, as shown in the figure below. This page framework mainly includes the Header component of Now and doesn't contain the display data of the Now application.

After the browser loads the application framework, we can see that the content display section of Now will show Loading stamps . At this point, the Now application is initiating GraphQL requests to retrieve data for the application. After a few seconds of waiting, the retrieval process is completed, and the Now application will display the latest user comments and likes (Stampers), as shown in the image below:

On this page, the initialization of the framework, all user data, and all images presented on the page are obtained through the gateway. These elements are computed and assembled into the complete Now page within the browser. The gateway provides the capability to load static resources, while the indexing service provides the ability to load dynamic data.

When a user wants to add a new blog post, they can use their wallet to upload the content to Arweave. This content will be marked with specific tags to facilitate GraphQL query functionality provided by the indexing service. After the successful upload of the blog, upon refreshing the Now application, the new content will be displayed within the content presentation of the application.

The diagram above illustrates the fundamental process of writing to and reading from Permaweb. In practical applications, both writing to and reading from Permaweb will be carried out through the service layer.

Scaling

The greatest advantage of microservices is scalability, and this feature will be fully inherited by the Now application. We can access Now using any of the following gateways:

• https://now.arweave.asia/

• https://now.arweave.dev/

• https://now.g8way.io/

• https://now.ar-io.dev/

Similar gateways can be horizontally scaled without limit, giving the Now application nearly unlimited performance capability.

The Best Practices of SCP

In the architecture of Permaweb, Arweave is only used as the storage layer. However, decentralized microservices should not be limited to this. We should deeply draw from the advantages of Permaweb and microservices architecture to explore the best engineering practices of SCP.

The following image is from the article Evolution of the Blockchain Application Model along with Changing Consensus, describing the future architecture of blockchain applications - users no longer interact with the blockchain system itself, but with the service layer. The evolution of blockchain applications is shown from Figure 1 to Figure 3, and more content can be read at:

https://news.ever.vision/evolution-of-the-blockchain-application-model-along-with-changing-consensus-755e4ae407a7

From Figure 3, it can be seen that the blockchain relied upon by the application is not limited to Arweave, Bitcoin and Ethereum are also other blockchain objects. These blockchains serve as the consensus source for the application, providing decentralization and trusted assurance. Similarly, Permaweb and decentralized microservices can also be expanded, with the storage layer not limited to Arweave. Bitcoin and Ethereum can also be used as storage layers, where the storage layer can also be other types of blockchains. One possible best practice architecture is shown in the image below:

Describing from bottom to top:

• Consensus Layer: After expanding Permaweb, renaming the original storage layer to the consensus layer is more appropriate. The consensus layer can be any blockchain system, possessing the properties of immutability and traceability.

• Service Layer: The key distinction between the service layer and Permaweb lies in the fact that the underlying standard protocol is not limited to Arweave storage, allowing microservices to be established for any blockchain system. Taking the indexing service as an example, Nansen provides data query capabilities for existing EVM public chains, and many DApps and frontend data can directly use Nansen as a data source. KNN3 also provides similar indexing capabilities, creating a standardized relational query layer for blockchain data and offering storage indexing compatibility with Arweave GraphQL. In this architecture, microservices have more standards and better compatibility with the consensus layer.

• Application Layer: Not limited to Permaweb applications, this architecture can support decentralized applications (Web3) and Web2 applications, fully compatible with the original architectural system.

Conclusion

When looking back at the evolution of computer software engineering over the past 30 years and considering the evolution of blockchain engineering over the past 10 years, it is necessary to reflect on whether a global virtual machine (such as EVM) combined with Layer2 scaling solutions is the ultimate solution for decentralized systems.

This article did not deeply explore the feasibility of Layer2 or sharding technologies, but instead provided another possibility for the way blockchain applications are approached. Using Arweave's Permaweb as an example, this article combined the Storage-based Consensus Paradigm (SCP) and the microservices architecture to reevaluate a feasible engineering solution. This solution not only has strong scalability but also empowers applications with decentralization features. More importantly, this solution is not a mere illusion but a practical architectural system that can be implemented.

Reference

1. https://mp.weixin.qq.com/s/rSttw02Xsq2-6IMU0_JMjw

2. https://news.ever.vision/evolution-of-the-blockchain-application-model-along-with-changing-consensus-755e4ae407a7

3. https://cookbook.g8way.io/

4. https://news.ever.vision/a-storage-based-computation-paradigm-enabled-by-arweave-de799ae8c424

5. https://permadao.notion.site/Brief-History-The-Development-of-Arweave-and-Storage-based-Consensus-Paradigm-SCP-d60aec0e8a4d4aafa33d536c6fdf4189

Token security is an oft-criticized topic in blockchain security. On blockchains, anyone can issue tokens, and the quality of these tokens varies. There are even hackers who maliciously issue tokens that can only be bought but not sold to scam users. In the blockchain industry, smart contracts are the law. Still, the terms of these contracts can only be identified by professional technical experts. It is difficult for users to distinguish between valid and secure tokens and malicious tokens in hundreds of lines of code.

imToken has created a token profile (https://github.com/consenlabs/token-profile), where token projects submit token information themselves on GitHub. Those submissions will be reviewed by an authority (imToken) before being displayed in the imToken wallet. If there is a malicious token, it is usually fed back to the authority by the user and re-audited by the authority, which is a long and troublesome process. everFinance has encountered malicious tokens EVER. The lengthy auditing process, which requires interfacing with various agencies and media, has dramatically delayed the flagging and publicizing of the malicious token. So, do we have a decentralized and more efficient token identification mechanism? And make the process of labeling tokens transparent and trustworthy, accurate and fast through financial incentives?

Common Auditing Process

The typical approach of token security relies on a centralized authority for auditing. The risk control mechanism for tokens is summarized in the flow shown below:

In the above figure, the token issuer or user submits token information. The status of the token audition is yellow. The authority will audit the token information and mark the tokens as green for secure tokens and red for risky tokens. If the authority audits the token incorrectly, auditing is started over, and the token status is re-labeled after re-auditing.

In the traditional security world, this process is repeated by an authority every time a new token is created. The user of the token information needs to trust the authority and wait for the authority's re-audit when the token information is faulty.

At the same time, the security of the token is repeatedly audited by different authorities, and absolute trust is not always reached for other authorities. We can see that security-related information is produced in a disparate and untrustworthy information network and managed independently by different authorities.

There are two crucial problems with the existing mechanism:

1. The applications completely trust and rely on the authorities. There is a massive single point of risk for the token information.

2. Security information is scattered among different authorities. There is a huge trust gap between authorities, with a time-consuming information-sharing process.

Authorities and Trust Gap

Trusting authorities generates a huge single point of risk. It is why many apps build their own security risk control systems. Single point of risk may lead to untimely token information updates or even wrong token information. When the business pays much attention to security, the application provider needs to conduct a repeated review of the content in addition to the authority, which reduces the efficiency but also increases the cost of sharing security information.

Due to trust issues, the security of the token is not quickly agreed upon among organizations. When a risky token is labeled, repeated audits and lengthy verification processes are often required between authorities before the final token security information can be updated.

Altcoin, Big Risk

For some small-cap altcoins, due to the high audit cost, it will lead to the fact that no authority verifies them. The authority will be alerted only when the altcoins lead to significant financial problems. Such security information lag commonly happens.

Using DAO to Govern Security

The Storage-based Consensus Paradigm (SCP) advocated by Arweave and everFinance opens up new possibilities in the field of token security:

1. No more trust gaps, token information is trustworthy, and the consensus of the DAO is the only trusted source

2. No more reliance on authorities, decentralizing token information so that anyone can get accurate information

3. No access control, any institution or individual can participate in DAO without permission

4. Faster token information validation, with DAO's economic incentive model incentivizing members to process new token information quickly

How to Build

Reasonable financial incentives are a vital element in creating a DAO. The traditional security auditing process cannot solve the consensus on security information or the single centralized point of risk.

We can develop a tokenDAO node, an off-chain smart contract for DAO members' collaboration. The node's code defines the template for uploading token information, the token mechanism, how to conduct voting, rewards and penalties, and other related rules.

There will be a token called TOK in tokenDAO. TOK is a profit-sharing community token, and anyone can go to everPay Swap to get TOK. TOK functions include: 

1. Incentivize correct token information uploads

2. Incentivize correct token labeling

3. Vote on token information

Token Upload

Token information will be uploaded to Arweave and must be uploaded according to the data template specified by tokenDAO. Incorrect data fields or duplicated uploads are considered invalid. Once valid data is uploaded to Arweave, it is loaded into the tokenDAO node. tokenDAO nodes automatically store the uploader address of each piece of data. TOK can be staked to each token information. The more TOKs are staked for each token information, the more TOK rewards the uploader receives. However, the TOK reward for the uploader is much lower than the reward for staking tokens for labeling since collecting information is much easier than labeling information.

Token Labelling

Any user holding a TOK can stake their TOK to valid token information. TOK staking is a ternary operation consisting of: no staking, stake the token as safe, and stake the token as scammy. When there is no staking, there are no rewards to the units of TOK. Staking a token as safe or scam can result in a reward or a penalty. The holder of a TOK needs to correctly determine if the token is malicious. The penalty for a wrong stake is greater than the reward of a correct stake to keep the quality of each stake and avoid arbitrary stakes.

A TOK can be staked to any number of token information. Different stakes can be chosen for different token information: stake for safe or for dangerous. A unit value of TOK is less profitable if it is staked to only one token, and most profitable if it is staked to all tokens in the network. A TOK can also be delegated to a third party to stake.

Information Correction

The graph shows the results generated by TOK stakes. The green bar represents the number of safe stakes, and the red bar represents the number of dangerous stakes. tokenA has a large amount of TOK staked as safe, while tokenC has a large amount of TOK staked as safe and a small amount staked as unsafe, which is a controversial token. If anyone staked for danger for tokenA, tokenA becomes a controversial token, and the token enters the uncertainty state.

Within n hours of the token being controversial, the user can choose to change the stake type, and if a new consensus is reached within n hours, the token is automatically released from dispute. If there is still a controversy after n hours, a voting phase will take place. Any user with a TOK can vote on the controversial token. Ultimately, the wrong side of the stake is forfeited and awarded to the voter and the staker with the correct choice.

How to Use tokenDAO

The DAO is entirely free, and anyone can download the tokenDAO node. Running the node will automatically sync token information from Arweave and generate staking and voting conditions for each token according to the transaction history on Arweave. Once the tokenDAO node is synced to the latest block on Arweave, users can access the tokenDAO API to get the latest, fully decentralized, secure token information consensus.

Conclusion

Arweave + SCP allows us to quickly create a domain-oriented PoS and DAO based on a domain-specific problem. The model can be adapted to a broader range of domains. Whether blockchainless DEX or decentralized new media mentioned in previous blogs, similar projects can all be economically incentivized by domain-oriented PoS design tokens. Arweave + SCP solves the consensus problem and provides developers with the freedom to develop architecture designs. Arweave + SCP will pave the technical path for WEB3.

Arweave’s permanent storage starts a new era of blockchain: distribute data and content without centralized distribution. Using the Storage-based Consensus Paradigm for content distribution, readers only need to trust the open source smart contract code to get content media with untampered and uncensored content through a decentralized approach. After reading this article, you will learn how to decentralize media content and make it available everywhere. Also, we can use token economics to decentralize the content creation process.

Lack of Data Decentralization

Traditional content distribution platform is a single node of centralized storage, with the growth of data volume or data censorship, some content will be actively or passively deleted or lost. At the same time, the platform may face closure in the future, and users will not be able to access pre existing information after the closure.

For news media of the Web2 era, as shown in the diagram above, journalists (orange ones) write their industry insights into content to provide media service for readers (blue ones) through centralized nodes. This content is elegantly presented by the nodes, and users can simply click on the website URL to get the content and data they want.

Unfortunately, when centralized nodes are shut down, readers have difficulty accessing the content and even lose access to historical content (including articles they have already read).

Using Arweave for storage ensures that data will never be lost, so data decentralization is easy to achieve. Content distributors simply pay a certain AR to store data in Arweave. However, it is not enough to store data permanently. A large amount of redundant data is stored permanently, and readers cannot write code or scripts to filter the unneeded data and transform useful data into content as developers do. They also don’t have the ability to write HTML and CSS code to visualize the original article data to readable contents. Of course, we can directly store HTML files to Arweave, but even though the data is already a web page, it still cannot be indexed and searched directly in the user's device. 

Decentralized data storage alone cannot solve the problem of data readability (visualization). When building decentralized news media, developers must not only consider permanent data storage, but also consider data readability and visualization. SCP is the last step for content decentralization, making it easier for everyone to enjoy Web3 experience.

Decentralization of News Media

A complete decentralized news media should not only store data on the blockchain, but also provide visualization of the data. Using SCP can enhance the experience: SCP allows anyone to run open source off-chain smart contract code at any time from their own device, restoring the historical status of all articles and displaying all article content onto the screen.

Decentralized news media needs to do two things.

1. Open source the node code so that anyone can get the code and re-run the node

2. Upload all data from the node to Arweave, and the open source node can automatically get the data and visualize the data into readable content

In the above diagram, the core node is the distribution end of the news. It is similar to the traditional architecture: the journalist (yellow ones) provides the content, which is displayed to the readers (blue ones) through News Core Node. The core node must be an open-source, central node with data upload function. The core node is responsible for the data presentation to the users and also uploads the content provided by the journalists to Arweave one by one.

The open source nature of the core nodes makes the media platform a smart contract. News article data is uploaded to Arweave's blocks continuously. Readers or operators who download and run the code can automatically download newly added data on Arweave and become a distribution node to provide content displaying services. The distribution node only needs to sync to data in the latest Arweave block to keep the content up-to-date.

If a decentralized news media uses the above architecture, when the media is shut down, anyone can recover and display the content using the data on the Arweave blockchain and the node's open source code.

Web3 news media does not require extensive modifications to Web2 ones. It only needs to replace the original storage solution to permanent storage on Arweave. Web2's high performance developing middleware will be the carrier for off-chain smart contracts, providing unlimited performance.

Decentralization of Content Production

The previous section mentioned the decentralization of content, so that any media that is shut down can be restored to a functioning node through the source code and Arweave's permanent data. However, in the above architecture, content providers still need to provide data upload services through centralized nodes, so can we also enable journalists to decentralize content writing without relying on centralized nodes? The answer is yes.

But if everyone submits data to Arweave, and the news media nodes load data without access control, a lot of junk news data will be generated, degrading the reading experience. The solution in the previous section is that the content is uploaded only by the core nodes, and the admin private keys of the core nodes have the ability to audit the data. At the same time, the other open source nodes download data from the content of the core private keys, thus not allowing spam news to “pollute” the news feed.

There are two issues that need to be addressed.

1. Content should not be uploaded centrally

2. Content should not be overrun with meaningless data

The key to solving both problems is token economics. Developers can integrate a token mechanism in the open source node that is specifically designed to focus on the functions of content uploading and spam data prevention. It is a domain-oriented PoS design.

Domain-oriented PoS designs are designed to solve domain-specific problems through proofs of stake. Traditional PoS are designed for generating new blocks and consensus protocols. These designs spend a lot of effort on consensus and no longer have the ability to develop proofs of stake for specific business domains. If we had to use traditional PoS to develop for specific business domains, the design architecture would be very complex and "messy".

Arweave's perpetual storage mechanism makes data immutable and traceable, and already guarantees consensus data storage. Developers developing on SCP do not need to worry about consensus issues for their applications, and using SCP allows developers to completely focus on domain-oriented PoS design.

How to decentralize content uploading?

The above figure uses a unique private key for data distribution. To improve this, we changed filtering by key to filtering by token. 

Native tokens integrated inside the open source node are called NEWS. Each NEWS has a unique ownership and can be transferred. Ownership and the transfer of ownership can use a Storage-based Consensus Paradigm: the account that owns NEWS can send the transaction metadata of transfer(amount, to) to Arweave, and other news nodes can get this transfer information from Arweave and perform the ownership transfer. This transfer information can be obtained by other news nodes from Arweave and the transfer of ownership can be performed. 

Based on the SCP, the nodes have a consistent state over the same Arweave block height. Therefore, the ownership of NEWS follows the change of Arweave block, and our content is distributed through Arweave, so the token ownership and content have the same time series.

Three wallet addresses A, B and C hold NEWS on Arweave and they can do content uploads as follows:

From block 101 to 103, A and B hold NEWS tokens, and the content uploaded by A and B can be downloaded and computed by the nodes; C has no NEWS tokens, so C's uploaded content will be filtered out by the nodes.

At block height 104, A transfers 1 NEWS to C.

In block 105 and 106, the node does not download A's content uploaded after block 104 because A does not have NEWS tokens; C holds NEWS, and C's new content can be downloaded by the node normally.

With the addition of the token mechanism, news uploading no longer depends on a single private key and can be done by any token holder. When the node is synchronized to the latest Arweave block height, the valid articles are those uploaded by A and B in blocks 102-103 and those uploaded by C in block 106; the content uploaded by C in 103 and by A in 105 are not included in the node.

How to Avoid Spam Content?

Tokens can not only replace keys for content uploads, but can also solve the problem of spam content. We can empower tokens with more functions, such as voting. NEWS holders can vote on the content they view, so we can design an effective voting incentive to encourage the display of high quality content. With the voting mechanism, nodes can process the voting data and rank the high quality content. Popular and high quality data will be in the headline. This also allows a decentralized and democratic recommendation system to be built.

The quality of news media may depend on the quality control ability of the news organization (centralized organization). At the start of the community, the centralized organization may need to hold more than 51% of the NEWS tokens to ensure the quality of the content voting. But as the decentralized community grows, the tokens will slowly be released to great journalists. A good token incentive will allow the tokens to be distributed and transferred appropriately, so that the best journalists will be rewarded more and quality content will be properly "headlined".

Conclusion

Web3 news media not only creates content distribution that cannot be turned off, but also allows for more reliable and efficient content production. Using the SCP architecture lowers the barrier to decentralized news media, makes smart contracts development much easier for normal web users, makes Web3 content displaying easier, and makes Web3 more widespread.

In the same way that token economics offers the possibility of content uploading and spam filtering for news media, a native token architecture based on SCP provides higher token performance, ensuring decentralization and native Web3. SCP will also reduce the cost of Web3 participation and interaction, instead of having the user paying more than 20 USD in gas fees for even a single upvote.

Token economics also allows decentralized news media nodes to become DAOs and off-chain news media nodes to become smart contracts. When we run a news media node, we can trust the node's open source code, and the node's mechanism determines the quality and reliability of the content produced on it. Ultimately, the production and distribution of content is no longer determined by an authority, but what we trust, a DAO —— code is law.

When we are talking about DEXs, we generally refer to smart contract programs that run on Ethereum like Uniswap. This post will describe how to build a DEX in a new way that combines the automated market-making capabilities of Uniswap and the same security properties as blockchains. Even better, the new DEX model provides nearly infinite scalability without the risk of MEV.

How Uniswap Works

The concept of automated market making originates from Uniswap. Hence, a new type of DEXs cannot be built in isolation from the design philosophy behind Uniswap, that is, using the simplest algorithm in combination with a blockchain to allow every user to be a market maker in place of specialized agencies.

The overall architecture of Uniswap v3 is shown in the figure above. The smart contracts of Uniswap v3 are executed in the EVM, which is run by every geth node. Hence, the computation process of v3 is performed by thousands of nodes, which reach a consensus via the PoW mechanism.

Take a closer look at the smart contracts of Uniswap v3. What Uniswap v3 essentially does is to aggregate NFTs by using the Router. Behind each of the NFTs is a liquidity pool provided by an individual user who sets a specific bonding curve and a price range for market-making. When a user sends a quote request to a v3 smart contract, the Router will generate the current best price by performing an aggregation computation. The user will sign a transaction at that price and send it to the Uniswap contract for execution. The transaction will lead to synchronous update of multiple NFTs, ensuring that the swap functionality of Uniswap is secure and reliable for users.

The Prototype of the Next-generation DEXs

Before creating a prototype, you need to learn about everPay and its bundle transaction. everPay is a blockchain-based financial infrastructure that combines Arweave and SCP. By offering real-time transfers and a verifiable ledger, everPay allows users and developers to conduct token settlement in real time.

In everPay, a bundle transaction is a type of opAction. It allows a many-to-many transfer that requires the signatures of all transfer parties. If any of the subtransactions in a bundle transaction fails, the entire bundle transaction will be rolled back. Generally speaking, a bundle transaction is a many-to-many transactional transfer functionality.

Now that you have learnt about how Uniswap v3 works, you can build a new generation of DEXs on top of the SCP basics and everPay's bundle transactions.

Firstly, the Router Contract in Uniswap v3 can be replaced by router nodes. A router node is a routing gateway node that can be deployed by anyone to collect the information of liquidity providers (LPs). Similar to the Router in v3, a router node can obtain the best price and swap path by performing aggregation computations when receiving a quote request.

Secondly, the NFTs  in Uniswap v3 can be replaced by LP nodes, which are in control of a private key and an automated signature program. The LP node program will make quotations and sign bundle transactions according to the user-defined curve and price range. When an LP node starts, it will connect with router nodes and submit quote information to them. Router nodes will send valid bundle transactions to LP nodes, which will sign the ones in compliance with their own market-making rules. The successfully signed transactions will be sent back to router nodes.

Transaction process:

1. A user sends a quote request to a router node.

2. The router node generates the best quote and swap path with information gathered from multiple liquidity providers.

   1. An instance of a bundle swap path: UserA transfers tokenA to lpB, lpB transfers tokenB to lpC, lpC transfers tokenC to userA.

3. If the user agrees with the quote, he will sign the transaction. And then the route node will ask all the LP nodes involved to sign it. The quote also needs to be confirmed by the LP nodes.

4. The router node will submit the bundle transaction to everPay for execution after it gathers all the signatures required.

Benefits of the Next Generation of DEXs:

1. A fully distributed P2P network that cannot be disrupted or shut down. Anyone can deploy a router node or an LP node in the network;

2. Infinite scalability. Every router node can connect with hundreds of LP nodes and provide aggregation services for tens of thousands of users. An unlimited number of router nodes can be deployed in the network.

3. No MEV. A user will be paid exactly the same price at which he signs the bundle transaction. If any of the LP nodes fails to pay the corresponding tokens, the entire bundle transaction will be rolled back, which means it does not happen at all.

4. Ultrahigh asset security. Since LP nodes have their own private key and assets in hand, hackers have to attack them one by one to steal their assets, which means the attack vectors are highly distributed.

Such a network offers an optimal user experience. You only need to access the UI that connects to a router node and then sign your transaction at the price provided by the router node. Since the router node communicates with all the LP nodes that connect to it by using websocket, the transaction can be signed in seconds and then executed by everPay in real time. In addition to the high-speed transaction processing, you can also benefit from no slippage because the quote you are offered is what you finally get. In this way, you do not need to worry about any MEV extraction conducted by flashbots, which is commonly seen on Ethereum.

The only drawback is that becoming an LP needs to run a node, but there are workarounds. For example, your mobile wallet can be an LP node. As long as you set a price range and select a market-making curve on your phone, you can utilize the idle assets in your wallet for automated arbitrage. You can participate in the DEX's swap network as if you were playing online games, and the program on your phone will stay online and conduct automated market-making according to your custom rules.

Conclusion

As is shown in the prototype above, we can build a decentralized application without any on-chain smart contract at an extremely low cost. Such a development mode conforms to the mindset of Web2 developers. We can expect that the rise of the Web3 era will go beyond blockchains and EVM and bring out more paradigms for building Web3 applications. The SCP proves to be an excellent option for Web3 development by providing applications with the immutability and traceability of blockchains as well as the scalability of large-scale systems.

This post is divided into three parts, each of which centers on the following content:

1. How Arweave Works

- Why is perpetual storage economically viable

- How does Arweave ensure miners store all the data

- Blockweave technology

- Implicit incentive mechanism

2. SmartWeave and SCP

- SmartWeave

- Storage-based Consensus Paradigm

- The Web3 Era of Infinite Scaling

- everPay Architecture

3. The Two-layer model that integrates Permanent Storage and PoS

- The Design of KYVE

- The Design of Koii that Integrates Permanent Storage and Pos

- Conclusion

Part3: The Two-layer model that Integrates Permanent Storage and PoS

This post is the third and final part of “Introducing Arweave’s Tech Ecosystem”.

After the SCP has been iterated and updated for more than half a year, we found that data verification is the core problem of the paradigm. SmartWeave cannot resist DDoS attacks because it fails to handle data verification properly. The validity of on-chain data is of utmost importance. Only when the data is valid and accurate can the usability and scalability of applications be ensured.

In everPay, the coordinator is responsible for data verification, which can be expanded to decentralized solutions.

Decentralized data verification solutions are used by a great number of projects in the Arweave ecosystem. All these projects conform to the SCP. Among them, SmartWeave is a typical example. Other projects built on Arweave, such as publish content platform koii, data archiving protocol KYVE and the oracle solution Redstone, are essentially designed according to the similar SCP model as everPay’s.

1 Design of KYVE

According to KYVE’s architecture, the data is uploaded by the uploader and then voted on by the Validators. KYVE ensures the validity of the data included on-chain and removes any invalid data so that clients do not need to load invalid data.

2 The Koii Design that Integrates Permanent Storage and PoS

Koii has built a fully decentralized consensus network with high scalability. It adds a PoS layer on top of the permanent storage chain Arweave. Only those who stake tokens are qualified to verify data in the Koii network. Any data verification performed by non-stakers are deemed invalid.

If a validator node which has staked tokens broadcasts false data, it’ll get slashed according to Koii’s PoS mechanism. As long as the number of tokens slashed reaches the threshold value, the node will be kicked out of the network. This way, Koii creates a fully decentralized task distributor.

For example, there might be 100 Koii nodes that can deal with simple computation tasks. Similar to the developers who write smart contracts in Solidity, the task distributor provides Koii nodes with task scripts for computation. The nodes that accomplish the tasks can obtain newly created tokens as rewards as long as they include the validated data onto the chain.

In the Koii network that contains 100 validator nodes, it barely requires three or four nodes instead of all the nodes to compete in order to execute a computation task distributed by the developer.

For example, the computation tasks of Application A and Application B can be handled by different nodes in the Koii network. As long as a computation task is done by a single node in the network, it will be computed and verified in an accurate way.

The SCP that integrates permanent storage and PoS has another advantage. The nodes that participate in staking cannot tamper with the computation results of a deterministic program, which means that the consensus is immutable. The consensus depends on a storage blockchain.

As the SCP suggests, a consensus reached on the basis of perpetual storage cannot be tampered with by third parties. Even if barely 1 million dollars of tokens are staked by validator nodes, projects worth 100 million or 1 billion dollars can run properly in the Koii network because staking only offers data verification capabilities instead of basic consensus protection.

Ultimately, a consensus is reached through the SCP. Intuitively, a Koii node is like an accountant who has no access to real assets. This makes it that it can only help accounts, but cannot change the consensus. This model has a great advantage over the traditional PoS mechanism. In the traditional PoS mechanisms, running a project worth 1 billion dollars requires 10 billion dollars worth of tokens to be staked. On the contrary, the PoS mechanism based on the SCP allows projects of great value to run on top of a relatively small number of stakes.

3 Conclusion

To sum up, the hybrid model that combines permanent storage and PoS is a way to build a dApp with the permanent storage chain Arweave as Layer 1 for perpetual storage and the PoS mechanism as Layer 2 on top of it.

The projects built on top of Arweave are not restricted to the DeFi field, but also cover every aspect of Web2. Ardrive is one of the examples. You can pay AR tokens to store an image on it and download the image whenever you need.

To give another example, the oracle solution Redstone aims to upload the validated pricing data to Arweave. Similar to everPay, Koii and KYVE, Redstone is also built with a staking mechanism. It verifies the pricing data of various tokens and stores it in Arweave, so that anyone can obtain accurate crypto prices.

Redstone can be considered as the Chainlink in the Web3 space. It allows all the applications built on the SCP to read the data from a storage blockchain to perform off-chain computations. The data accuracy is ensured by the economic mechanism of Redstone.

Thanks to the hybrid model, all the business programs that perform computations off-chain can offer an optimal user experience and extremely high TPS. Besides, the applications built on the SCP benefit from the characteristics of decentralization, which are,traceability, immutability and trustlessness.

This post is divided into three parts, each of which centers on the following content:

1. How Arweave Works

- Why is perpetual storage economically viable

- How does Arweave ensure miners store all the data

- Blockweave technology

- Implicit incentive mechanism

2. SmartWeave and SCP

- SmartWeave

- Storage-based Consensus Paradigm

- The Web3 Era of Infinite Scaling

- everPay Architecture

3. The Two-layer model that integrates Permanent Storage and PoS

- The Design of KYVE

- The Design of Koii that Integrates Permanent Storage and Pos

- Conclusion

SmartWeave and SCP

This is the second part of “Introducing Arweave’s Tech Ecosystem”. This post will discuss perpetual storage and consensus computation.

1. SmartWeave

When I first learned about Arweave last July (2020), I was aware that it would be a game-changing underlying blockchain. It occurred to me that a blockchain or cloud storage designed for perpetual storage could be considered as a tape of a Turing machine.

As we all know, a Turing machine is composed of a state machine and an infinitely long tape. Arweave is ideal for serving as a tape. We can write a program that is able to perform any computation and store it in Arweave with all the data.

For example, when you create a financial statement using Excel on your personal computer and send it to others, they cannot confirm whether your financial statement is authentic.

However, if the hard drives of the computer are replaced with a storage blockchain, the financial statement can be trusted with all the data stored on-chain and computations done by independent clients in a distributed way.

Hence, we believe that as long as the data stored on-chain is trustable, computations can be performed in any compute unit and the results computed on immutable data via a deterministic program are unique and trustable.

In Bitcoin, the ledger is created using the PoW mechanism, which helps build a consensus. However, with Arweave using hard drives instead, each operation and its steps performed on your personal computer will be recorded on-chain.

Hence, the current state is always traceable and verifiable. Although it seems to be a radically new model, it is actually a classical model that returns to the essence of computers. It ensures that every file is traceable and immutable with no need to perform computations on-chain like Ethereum.

As long as a deterministic program is uploaded to Arweave, it can be downloaded by anyone and can automatically load the data on-chain to perform computations. In this case, any computation result can be considered as an objective fact or a consensus. So how is SmartWeave able to make all this possible?

SmartWeave is a virtual machine that runs off-chain. It can read the running code of applications, load all the input parameters from Arweave, and then locally execute each of the transactions required. After that, Smartweave syncs up with the latest Arweave block so that it can generate the latest finalized state.

The code of smart contracts is not executed on-chain at all.

Arweave can guarantee the authenticity of the code stored in an Arweave transaction, which can be a token contract, for example. The state of the contract and all the relevant operations are the outcome of users sending Arweave transactions.

Although it sounds perfect, SmartWeave has a weak spot for its inability to avoid DDoS attacks. A DDoS attack means that a hacker sends a massive amount of invalid transaction data that will not be executed successfully.

Since SmartWeave cannot tell which data is valid before executing transactions, the SmartWeave clients have to keep loading the data to compute the results. If there are multiple gigabytes of invalid transactions, SmartWeave will suffer from low availability, but its security and consensus remain unaffected.

2. Storage-based Consensus Paradigm

Figure 1 shows the Bitcoin model. Before you make a transfer using Bitcoin, you need to run a full node or SPV node on your personal computer to recompute Bitcoin’s ledger.

However, since 2017, the proxy model adopted by MetaMask and imtoken has gained popularity. In this model, application operators deploy full nodes on Ethereum and Bitcoin for users to request data and send transactions.

Similar to the Figure 1 Bitcoin model, the SmartWeave model requires users to perform computations and send transactions on their own. However, in the proxy model shown in Figure 2, proxies like MetaMask can display a false balance for users, but they cannot change the consensus.

Whoever performs a computation on the consensus data through a specific program must obtain an identical and unique result. Anyone who runs a node is unlikely to obtain a false state by computation. The same goes for SmartWeave — all the calculated results are finalized.

Taking one step further, we can discover that users no longer need to interact with blockchains on their own. Instead, they only need to access the application clients that interact with blockchains.

Take SmartWeave for example, it depends on an application client, which can be run on the provider’s server, to perform off-chain computations. A perpetual storage blockchain allows the server to be a deterministic and traceable program with the same characteristics as a blockchain.

1) Relative Consensus and Absolute Consensus

Why do users no longer need to access blockchains directly? To find out the answer, you need to understand the concepts of relative consensus and absolute consensus.

For example, an eth node shown on the left is deployed by imtoken. When you send a transaction using imToken, the transaction is relayed to the eth node via the imToken gateway.

In this case, you completely trust a third party that can forge data, which is called relative consensus. On the contrary, if you deploy a node on your own to execute all the transactions without relying on any third party, this is called absolute consensus.

The proxy model allows users to use many DeFi products, which usually provide an APR for yield mining. To obtain an actual and reliable APR, users must perform computations on their own.

When users rely on centralized nodes to provide slightly abstract data like APR, the third-party servers can offer a false APR to them, but they cannot change the consensus on transfers. To go one step further, third-party nodes can be trusted to compute the basic information of transfers like balance. They simply need to provide a user-friendly API.

So we’ve built the Trusted APP model, in which a Trusted App takes the place of blockchains to interact with users. Decoupling users from blockchains is the key to lowering the user threshold and increasing TPS.

2) Trusted APP

This model has the following advantages:

• Composability

The Trusted APP offers composability on the basis of data partitioning. When composing with each other, Application A can download the data of Application B from the storage blockchain and verify it according to the business rules of Application B, thus achieving multi-ledger verification.

It allows us to only integrate the data of applications that we care about for verification. This model greatly improves the composability of traditional businesses using a blockchain. It reminds me of the days when I worked at a bank.

During the period, I was responsible for multi-party account checking and found it painful to do it in a traditional way. Everyday I was sent a text file to check my ledger with the third-party ledger. Such a semi-manual method is error-prone. If any error occurs, reversal is required.

However, with Arweave storing all the data, the multi-party account checking can be done via an automated program. This can help create a ledger that is very close to Bitoin’s. All the DeFi and traditional applications can be composed in this way so that account checking can be done per block instead of per day.

• Low development barriers

The storage-based consensus paradigm greatly reduces barriers to development. As I once demonstrated, it is quite simple to write a SmartWeave contract with custom states in JavaScript.

Imagine that the balance state of an application is state.balance, the registration state of an email address is state.registered, and the state of a perpetually stored file is state.file_id. The paradigm makes development quite simple and flexible without any limitation to programming languages.

The PST tokens on Arweave conform to a specific standard like ERC20 tokens and have some general APIs for states. However, there is no restriction on the development of Web2 and Web3 applications so that developers can flexibly utilize the advantages of SmartWeave.

More importantly, you do not have to write smart contracts in JavaScript or use SmartWeave. As far as I am concerned, SmartWeave is just one of the examples of the storage-based consensus paradigm.

With its perpetually trustable storage supporting consensus computation, Arweave becomes a tape of a Turing machine so that you can build any Turing-complete application. And you can go even further by replacing SmartWeave with your own back-end program, which will have the outstanding properties of a blockchain.

Given that SmartWeave can’t prevent DDoS attacks, we have transformed its model by using a high-performance back-end server instead to receive users’ transactions. Despite its resistance to DDoS attacks, the improved model has a disadvantage because the independent back-end server can filter and censor users’ transactions.

However, the back-end server is unable to change the objective states because all the transactions included into the chain are signed by users themselves. The improved model can resist DDoS attacks that SmartWeave is vulnerable to, while offering the same development mode as Web2.

• Infinite TPS

Besides, the TPS of applications is infinite because the server can roll up a batch of 10,000 or 100,000 transactions in a single block and then include it into Arweave. In this process, a temporary state will be waiting in line.

A batch of transaction data is rolled up into Arweave every 5 to 10 minutes so that the corresponding state will be finalized. No matter what server your program runs on, you can easily build a trustful Web3 application by using Arweave as perpetual storage.

To make this model more abstract, you can build a Web3 application by combining a storage blockchain with AWS or Google Cloud. With Arweave guaranteeing the immutability and traceability of input data, a deterministic business program can ensure the uniqueness and finality of output data.

How can we apply this model to DeFi? The API of a Trusted APP offers real-time data verification and inclusion into the chain. Multi-party ledger verification is required in the DeFi field. When integrating a token or a lending protocol like Compound, a DEX needs to download their business programs and historical data from Arweave.

For example, it can integrate the JavaScript code of SmartWeave for calculation and data verification. You can write your own program in any programming language like Golang or Rust to convert the deterministic rules of other applications into the language that you use. And you can integrate these applications into your own one simply by using their SDKs.

3) The Web3 Era of Infinite Scaling

The storage-based consensus paradigm is expected to create a Web3 era of infinite scaling. As shown in the figure above, on the left is the token payment and settlement protocol everPay, on the right is an AMM program, and at the bottom is SNX.

All these applications store their business data on a storage blockchain with their consensus data computed by detectors. They communicate with each other via HTTP in real time, and the communication results can be verified and reversed afterwards. Since everPay can obtain all the data of the AMM and check the AMM’s consensus with a specialized program, it can compute the final state of the AMM. As long as the latest data of the AMM is rolled up into the storage blockchain, the three applications will obtain the same result when computing the AMM’s state.

everPay can tell if other applications are deterministic and fraudulent. The applications interact with each other via traditional Web2 APIs in real time. Once the data is included into the chain, the entire state will be finalized.

Hence, the temporary state generated during interaction will also be finalized. Besides, the storage-based consensus paradigm does not require each of the applications to use the same storage blockchain.

To be specific, an application that uses Arweave can still compose with another application that uses a different storage mode. For example, an AMM uses a storage blockchain different from everPay. If everPay wants to verify the AMM, it can read its data directly from the storage blockchain used by the AMM for computation and verification. That is how composability is realized.

3. everpay

everPay is a dApp of both Ethereum and Arweave. When using everPay, we can directly connect to it via the Ethereum wallet MetaMask, or the Arweave wallet ArConnect. In the future, everPay will add support for more blockchains such as Solana and Near. The flexibility of off-chain computation allows us to build various cryptographic implementations with Golang. For now, everPay is more like a Layer 2 application that offers real-time token transfer and a bridge between Arweave and Ethereum.

Before using everPay for the first time, you need to make a deposit. In everPay, all the assets are managed by a DAO, whose members have a multisig contract on Ethereum and Arweave respectively.

When you make a deposit to an address managed by the DAO, the transaction will be sent to everPay, which will check if the transaction is confirmed by 15 blocks on Arweave. If the transaction is validated, the deposit will be mapped 1:1 to everPay. It means that the deposit address will hold the same amount of newly-created tokens, which can be controlled by the original wallet.

When you transfer, for example, 1 USDC token, the receiver address can be an ETH or AR address. Any ETH or AR address is considered a valid everPay account. When making a transfer, you need to sign the transaction via MetaMask.

In the figure above, you can see the transfer amount and the fee of the transaction, which will be directly sent to the server. If you switch to the receiver wallet on Arweave and connect it to everPay, you will find its address is totally different from the ETH address. And you will see the transfer transaction in the transaction history of your everPay account.

By performing computations off-chain, everPay offers extremely high performance. Similar to PayPal and Stripe, everPay can utilize various back-end programs to build high-performance applications. However, all the everPay transaction data will be rolled up into Arweave so that the everPay ledger has the same characteristics as a blockchain.

everPay Architecture

The entire architecture of everPay is shown in the following figure. It contains three roles:

Coordinator:

The coordinator is analogous to the sequencer in a zkRollup. All the users’ transactions are sent to the coordinator for real-time computation on a first-come, first executed basis, so as to get finalized.

Since users’ transactions are confirmed as soon as they are received by the coordinator, there is no such thing as a pending transaction in everPay. If a transaction is sent successfully, it will be added to a transaction pool and wait for being included into the chain; if not, it will return an error to the front end and will not be added into the pool. The transactions in the pool are included into Arweave by batches every 5 to 10 minutes.

The business program run by the coordinator is consistent with those run by watchmen and detectors. Each role loads data alone from Arweave for independent computation and verification.

Detector:

Similar to Infra, a detector offers all the transfer and balance information after it is deployed. Users can obtain the ultimate state of the ledger from detectors.

Watchman:

A watchman takes charge of multisig governance in cross-chain interactions. It can be considered as a detector in control of a private key. When a watchman detects any withdrawal data on Arweave, it will create a withdrawal proposal. If you want to withdraw tokens native to Ethereum, watchmen will verify your transaction and sign a withdrawal proposal. Your transaction will be executed on Ethereum or Arweave only when it is signed by over 51% watchmen.

The ledger synchronization among watchmen, detectors and the coordinator completely depends on Arweave instead of P2P communication. All the roles will verify the entire ledger on their own. After verification, watchmen need to sign a proposal.

Building applications on top of the SCP with Arweave as storage infrastructure will become a real trend in the Web3 era. everPay is a typical Web3 application that offers nearly the same TPS as a traditional Web2 application and operates as a DAO.

Take mirror.xyz as an example. We published the everPay lightpaper on Mirror. Although Mirror runs on a centralized server, all the file data is stored in Arweave, while the corresponding NFTs are minted on Ethereum, which is completely in conformity with the SCP model.

Perpetual storage is the key to the SCP. By using a blockchain like Ethereum as the back end, your applications do not need to run completely on-chain or in a fully decentralized way. In fact, decentralized storage allows users to store their files permanently via a centralized service instead of sending a transaction on their own.

Furthermore, asset transfer might also benefit from the SCP model. By expanding the value flow, everPay does not require users to send transactions on their own. It allows asset mapping cross-chain, making blockchains on longer difficult to use.

everPay currently supports Arweave and Ethereum, and will be able to integrate any blockchain in the future. everPay offers real-time transfers and almost the same user experience as traditional transfers.

It will add support for smart contract accounts, which are costly on-chain, but are much cheaper off-chain. everPay’s smart contract accounts will provide decentralized security and an optimal user experience at a relatively low cost in consensus building.

This post is divided into three parts, each of which centers on the following content:

1. How Arweave Works

- Why is perpetual storage economically viable

- How does Arweave ensure miners store all the data

- Blockweave technology

- Implicit incentive mechanism

2. SmartWeave and SCP

- SmartWeave

- Storage-based Consensus Paradigm

- The Web3 Era of Infinite Scaling

- everPay Architecture

3. The Two-layer model that integrates Permanent Storage and PoS

- The Design of KYVE

- The Design of Koii that Integrates Permanent Storage and Pos

- Conclusion

Part1: How Arweave Works

This is the first part of "Introducing Arweave's Tech Ecosystem".

Hello, everyone! I dove into the blockchain industry in 2018 as a developer at imToken to work on the DEX Tokenlon and its iterations. During this period, I had been studying DeFi, I became an early user and researcher of the popular Uniswap as well as Compound.

When developing for imToken and interacting with DeFi apps, I encountered numerous problems. For example, managing seed phrases and paying miner fees is hard for users to comprehend. Over the past few years, I have been trying to recommend some friends of mine working at Alibaba and banking to use decentralized light wallets. However, it turns out that decentralized wallets are still desperately unpopular for their high user threshold. Fortunately, I saw a new direction for lowering the user threshold when I learned about SmartWeave, which is Arweave’s smart contract protocol, from UncleMeow, and the perpetual storage blockchain Arweave from ZengMi at a seminar held by SparkPool last July.

Since the established public chains like Ethereum are inherently unable to provide a premium experience for ordinary users at the infrastructure level, even the most elaborately devised products cannot remove obstacles to the use of blockchains. However, Arweave has the potential to become the basis of a new paradigm, making the blockchain world truly open to ordinary users.

When you perpetually store a file in Arweave, the file data will be stored by hundreds of nodes and can be accessed by Arweave gateway or any of the Arweave nodes.

Before being part of the blockchain industry, I studied IPFS and learned how to use distributed hash tables to retrieve data across the network in a decentralized way. However, IPFS has its own flaws for lack of an incentive layer for file data storage. For example, when your server shuts down, your file might disappear if it is not synchronized by the network.

Arweave builds a new mechanism for perpetual storage. What makes it different from Filecoin is that it charges a one-time, up-front fee for perpetual storage, which is made possible by its unique theoretical model.

1 Why is perpetual storage economically viable?

To answer this question, we need to understand the fact that the storage cost is decreasing over time, which conforms to Moore's law. According to official statistics, the storage cost reduces by nearly 30% every year. This makes it possible for us to calculate the total cost of perpetual storage, which converges to a constant as the storage cost keeps going down. In Arweave, the constant is weighted to determine the fee charged for storing data permanently.

2 How does Arweave ensure miners store all the data?

So how does Arweave prevent the loss of files stored in it? Behind it is data staking at play.

On Arweave, data is deemed valid after it is included into the chain. Miners can stake any amount of valid data, for example, 10 MB or even 20 TB (i.e. the entire data size of the network). For miners, the more data they store, the more AR tokens they can obtain. This makes it so that miners are incentivized to store data in Arweave.

3 Blockweave technology

The core technology that powers Arweave is the blockweave. How does the blockweave work?

Simply put, it requires a random historical block to create a new block. It means that the miner who stores the largest number of historical blocks is the most likely to mine a new block. If a miner does not store the required historical data, the hashrate that he needs to mine a new block will increase exponentially.

That being said, storing more data is the optimal and most profitable option for miners.

4 Implicit Incentive Mechanism

Besides, there is an implicit incentive mechanism on Arweave that protects users against file loss. When a chunk of scarce file data is required in a new block, the miners that happen to store it have advantages over other miners, who have to consume more computing power to solve the PoW puzzle.

Obviously, storing scarce data makes it faster for miners to mine a new block. In order to increase their competitiveness in mining, miners are incentivized to synchronize scarce data, which will become no longer scarce.

As a consequence, the files you store in Arweave will be spread all over the network in a distributed way to avoid being lost to the greatest extent.

What is a SCP？

In Ethereum’s model, computations are executed by all the full nodes, which then generates and stores the global state for query. Different from it, the SCP manages to separate computation from storage. To be more specific, the blockchain is merely used for data storage, while the off-chain clients/servers are responsible for executing all the computations and storing all the states generated.

The SCP uses off-chain smart contracts, which can be written in any programming language, with all the inputs coming from a storage-based blockchain. In this paradigm, the blockchain is very much like a hard drive and the off-chain smart contracts can be run on any device with computing capabilities. Using a blockchain as a hard drive ensures the immutability and traceability of the stored data, which is thus guaranteed to be trusted. As a result, off-chain smart contracts can ensure the ultimate consistency of state by performing computations on trustable data. 

The applications built on top of the SCP feature both the transparency and trustworthiness of blockchains as well as the high performance and availability of traditional internet applications. The SCP has the following advantages:

1. Composability: Business operations between traditional financial services requires account checking, which is complex and error-prone. Using a SCP can include all the financial transaction records in the blockchain, thereby converting the traditional financial services into blockchain applications. This facilitates not only automated account checking, but also rapid coordination and efficient combination of applications.

2. Low Development Barriers: Smart contracts are required to be written in Solidity using an EVM, while off-chain computation programs can be written in any programming language. That Makes it so developers can convert traditional applications into blockchain applications.

3. No Performance Limitation: Off-chain computation delivers superior performances similar to traditional applications because the off-chain servers can process massive transactions. In this way, the TPS merely depends on the machine performance of servers and the technical architecture of applications.

4. Low Consensus Cost: It merely costs 1 dollar to process a million transactions.

Improving SmartWeave in practice

The SCP is designed by the inspirations of Arweave’s smart contract SmartWeave and Ethereum’s L2 scaling solution Rollup, which improves their availability.

SmartWeave is a smart contracting platform built on top of the Arweave network. It allows users and developers to build programs whose execution is trustable and decentralized. One of the unique features of SmartWeave is the process of lazy evaluation, which removes the burden of processing smart contracts from the nodes and moves it to the users. This means that, instead of running every piece of code on every machine in the network, contract states are computed locally on the machines that request them.

SmartWeave is a decentralized contract platform that is open to all. The off-chain computation enabled by SmartWeave delivers higher scalability at the expense of introducing a new problem. The problem lies in that SmartWeave is prone to DDoS attacks, which means a large amount of invalid data is transmitted to all the computing nodes via Arweave, leading to latency in consensus and unavailability. When DDoS attackers maliciously send massive false transactions to the blockchain, node clients have to download them before verifying, therefore taking up a large part of bandwidth. In this case, valid transactions are submerged in the flood of false transactions, lowering the accuracy rate of data. To some extent, DDoS attacks may even lead to latency in client state computation.

To prevent DDoS attacks and ensure the availability of applications, everFinance has introduced a coordinator to compute and verify all the data of applications for the first time, and then includes batches of data into the chain. The coordinator acts like a rollup built on top of Ethereum by packaging transactions in batches, then including them into the chain. All the data packaged can be verified, SmartWeave’s “lazy evaluation” ensures verifiability, and Rollups guarantee the data accuracy which helps avoid DDoS attacks.

Reference

• SmartWeave: Arweave smart contracts

• A Storage-based Computation Paradigm Enabled by Arweave

• A Speech on IPFSNEWS’s Blockchain Forum: A Storage Application Paradigm

• AMA recap with Chris by SnapFingers about Arweave, storage and more

• Evolution of the Blockchain Application Model along with Changing Consensus