Google Drive
Gist
Clipboard
WP version: 0.7.0 (draft)
Author: Leona Hioki
A Layer3 on Intmax zkRollup with enough scalability and privacy to run web applications on it. This provides an infrastructure with the following properties as its essential functions,
(1) Deploying web application logics on the zkRollup storage.
(2) Privacy of user accounts.
(3) Buying and selling deployed and operated web application/websites on the DEX on Intmax zkRollup.
If you prefer a zkRollup-focused explanation, please move on to Intmax zkRollup paper (https://hackmd.io/RiATF7x4SqulGKauij9qKQ).
The Web protocol is standardized as TCP/IP and many server software frameworks exist in the current Web, but server and domain operations are not standardized. Server operations on the backend are hidden and difficult to audit from the outside, while user data is seldom hidden from the insiders. It needs to be the other way around, as will be discussed later. The backend must be audited, and user data must be hidden. For instance, applications on Ethereum have pseudonymous accounts and auditable backends, what we call smart contracts. The tradeoff is that their execution is extremely inefficient due to decentralization, and user privacy is insufficient. The tradeoffs can be summarized in the following manner.
zkRollup, a scaling solution in Ethereum, can significantly improve efficiency, and the ZKP used there plays a crucial role in improving privacy.
Intmax zkRollup provides auditable backends and user privacy to users and developers at a low cost.
This section explains the reasons why auditability of the backend and user privacy are desirable.
Auditability of the backend has the effect of eliminating SPOFs. It would facilitate the participation of trustless or trusted nodes in the backend of a single web application, allowing for redundancy and scaling at a lower cost, and simplifying the transfer of system ownership.
The backend server-side running many of today’s web applications are redundant and parallelized to eliminate SPOFs in server configurations called Multi-AZ, a kind of distribution of data centers. Load balancers with health checks distribute accesses.
However, a single entity runs the backend with no verifiability in almost all cases, so SPOF exists in the governance of the operating organization. Verifiable backends solve this problem, even in dynamic websites. Ethereum-type smart contracts and ZKP circuits are well-known solutions, and parallelization of Docker containers with a limit of behaviors is another solution. These allow the backend always to be open to trustless or trusted new entries of external nodes.
These solutions will solve the systemic and legal SPOF of parts of today’s Dapps like DeFi and ordinal web applications. This effect puts ownership of these to DEX instead of the stock market and M&A market and brings a new level of software reliability.
Next, we discuss the difference between legal governance and code governance means of ownership transfer. We see that ownership of current web applications comes down to the governance of a legal entity to which it belongs. Securities define ownership, and holders can influence the operating company through voting rights at shareholder meetings and other legal means. This process is opaque, and ownership is ambiguous and different from actual ownership.
On the other hand, if the backend server-side has the same characteristics as a dapp, this ownership is directly enforceable at a deeper layer. Moving the system to another server is always enforceable, and ownership always corresponds to actual control of the system. This change allows many outsiders to participate in operating and owning a system and can change the assumptions of the economies involved in the web.
DAO-like development, which is becoming common in the crypto space, can be extended to general web development with a high degree of standardization and maintainability. The ownership market for the general web applications will bring a shift from stock exchanges and M&A markets to DEX and DeFi.
Next, we will discuss the effects of improving user privacy at the protocol level. Privacy of user data is originally needed for economic fairness, to prevent monopoly. GDPR law is based on that requirement. The problem with the current web industry operations and regulations is not the means but the result. The problem is that backend operators have no incentive to keep user data secure.
Data preservations are based on legal requirements, but they are very costly, and the economic incentive is negative because the data is not available for advertisements. If this depends on the entities, the game structure becomes a chicken game or the race to the bottom. Each entity will continue to abdicate this obligation until legal sanctions or social reputational damage occurs.
Privacy assurance at the architectural level can change the game structure and prevent this race to the bottom.
This chapter describes how to make static and dynamic web pages trustless or verifiable and fully manage their rights and ownership on zkRollup.
In short, it uses separation of liveness and safety, separation of user and shared areas, and client-side validation based on the Verifiable Database.
We apply the Verifiable Database, a method that allows nodes that do not have a full database to validate transactions. The most famous Verifiable Database is the Merkle tree. While various crypto projects have used only this part for the long-term safety of assets by mistake, the Intmax project only uses this part to verify the front-end HTML construction, i.e., to prevent fishing and spoofing. Regarding anti-phishing, considering the possibility of double payments or rollbacks is unnecessary, and new security assumptions like timeout can be deployed. The separation of safety and liveness described in the previous chapter can be strengthened, enabling verifiable and scalable front-end HTML to be built on the server side instead of guaranteeing the liveness of the website.
When static files are stored in the Data Availability Layer, it is generally possible to give the address of the area to map or redirect domain URLs to the static files that are the content of the page. A hash of the recorded page content would allow for the verification.
Whether or not to allow updates, including deletion of pages, and how to set the conditions and permissions for updates, would be configurable from the time the website is deployed, and would have the same characteristics as smart contracts on Ethereum.
Also noteworthy is that these do not interfere with caching or acceleration by the CDN. For static website hosting, using a CDN for public access is not a problem as long as the last backup is on the Data Availability Layer is guaranteed. The redirection feature described above is in charge of CDN access.
Buying and selling a static website is as simple as deploying it. The simple way is the transfer of deployer's permissions to a buyer, expressed as a transfer of write permissions in the Data Availability Layer. Complex authorization configurations make DEX transactions more convoluted. The identity of the static website before and after the transaction is guaranteed because the content delivery of the Data Availability Layer is identical. Ownership can be tokenized as NFTs, and exchanges of those ownerships are the same as typical NFT exchange user-ability.
Assuming that the composition of the front-end HTML is constructed through conditional branches according to queries and database contents, these processes can be verified on the client side via a Merkle proof of the source code and database contents with their Merkle proofs if the back-end source code is not kept secret. If the back-end source code is confidential to the client side, the client-side can execute the zkSNARKs/STARKs verification with the verifying key registered in the Verifiable Database.
In this process, the data availability issue is again only a liveness issue and does not get into a safety issue such as fishing. The client-side validation will error out if the wrong front-end is sent.
Using zkp for the back-end does not require usual zkp security, which is responsible for the security of the asset. It is possible to introduce a new security assumption -timeout- for the construction of the front end, and it is possible to introduce zkp with a quasi-exponential time attack duration or zkp with optimistic security parameters. This would allow for much faster zkp calculations than zkp with exponential time security and would be a practical approach concerning website construction.
For updating user data records, we can introduce further speedups using p2p contracts, i.e., state channels. For each hosting node of a website, a p2p state channel can be opened with each user, allowing individual updates of the User Asset Storage. As mentioned before, since Intmax already separates per-user storage from commonly shared storage, building this state channel can be done by simply reusing Intmax zkRollup's state format. Users secure their own account data by periodic commit/close of the channel at L2. With this reuse of this state format, the Intmax Project is very well suited for fractal scaling, and the state channel can simply function as a kind of Layer3.
The document for this part is on the following link.
https://hackmd.io/@jxfHpm03SqCd40LGdz70Ow/r1MFi8-yo
-
Any changes
Be notified of any changes
-
Mention me
Be notified of mention me
-
Unsubscribe
Subscribe