- Details
The original design of PoV (Proof of Value) was merely to create a decentralized reward mechanism for DApp developers. Here is a diagram illustrating the consensus on this governance discussed today. The focus of the discussion is on the left side:
I am now considering the possibility of applying PoV to EIPs (Ethereum Improvement Proposals) or AI. The reasons are as follows:
- The Ethereum community (including the Ethereum Foundation) lacks sufficient understanding of finance. Putting technology aside, from a financial perspective, Bitcoin’s PoW (Proof of Work) demonstrates that Satoshi Nakamoto understood that finance is the most fundamental governance tool in the human world! From the initial adoption of Bitcoin's PoW, transitioning to the PoW and PoS hybrid of Casper, and finally to the current PoS, I have repeatedly seen or heard Vitalik discussing Ethereum's governance consensus, where he always emphasizes decentralization and security. His emphasis is correct, but from a governance perspective, from adopting Bitcoin's pioneering PoW to Peercoin's pioneering PoS, and with its continuous improvements, Ethereum's degree of decentralization and security have indeed been enhanced. But it has not innovated or even improved much in finance, on the contrary, some permanent flaws (like ICO) were left behind...
- One important piece of evidence related to this topic is the development of EIPs, which inherited Bitcoin’s decentralized collaboration model (BIP) from 2015 and has thrived over nearly nine years! However, the Ethereum community and the Ethereum Foundation have never established any reward mechanism for EIP contributors! Isn't this unfair compared to miners (validators)? If you knew how many dollars the Ethereum Foundation, with its extremely opaque financial reports, has donated to other projects, I guess some people would be furious!
- The application of AI is starting to explode. But Samuel Harris Altman, deified by OpenAI, has a very limited financial understanding, epitomized by Worldcoin! Yes, Worldcoin is a synonym for financial naivety. I once thought that AI might eventually need to be integrated with blockchain, so I didn't consider its financial governance methods carefully for the past six or seven years. But after a long period of observation and communication with a team member from an AI and digital economy research institute, I, a novice in AI, finally understood: a layman should not make assumptions but rather let other experts find the solution. Now we should provide AI with DAism's marvelous financial governance consensus! Though, originally, the focus of this discussion is not AI.
- So, ultimately, my idea is to actively promote the application of PoV in EIPs (Ethereum Improvement Proposals). Others can do whatever they want. We will fully open up PoV!
After sharing these thoughts with the team members, we reached a consensus.
Therefore, this is good news for all outstanding EIP developers: DAism’s PoV will bring you lifetime rewards!
Here’s the key point:
- If you are about to submit an EIP, please wait. You should first look at DAism’s documentation and follow these recommendations:
- If your EIP is the core or main part of your DApp under development, please complete your DApp and deploy it on the Ethereum mainnet, using it to mint a smart public device. Then share your technical innovation elsewhere (hopefully still following the current EIP content format).
- If your EIP is a pure technical innovation like EIP-7702 or an improvement to the underlying Ethereum protocol like EIP-158, the former being a general method not sufficient to become a specific DApp and the latter unrelated to DApps (reminder, only ERC-category EIPs are related to DApps), you should still carefully read DAism’s documentation and then write a smart contract for your EIP, deploy it on the Ethereum mainnet, and use it to mint a smart public device. When minting, the naming rule for the valuation token is: abbreviation of the smart public device.eip.
- If you have already submitted an EIP, you should also read DAism’s documentation and follow these recommendations:
- If it’s the case described in "1.a," follow the recommendations there. The existing EIP can be left as is.
- If it’s the case described in "1.b," follow the recommendations there. Then, add a line at the end of the Authors section of the already published EIP on ethereum.org. The format should be “Owner your wallet address.” Note that your wallet address must match the owner’s wallet address of the smart contract you deployed on the Ethereum mainnet. This will allow others to verify that a certain smart contract on the chain is indeed supplemented by the author of a certain EIP. Considering the security issues, all EIP authors should act quickly and preferably complete it within the short term of DAism going on-chain.
Maybe you have understood: in the future, all EIPs should be published directly on the chain (maybe in the SVG format logo of your smart public device)! Whether you promote it elsewhere is up to you.
For AI developers, you should also follow the method described in "2.b," writing "Owner your wallet address" in the readme.MD document of your open-source code. However, I must point out that this method is unreliable because your code hosting site, like GitHub, could be hacked, or its administrators might act maliciously (in the anonymous world, you can never recover your losses once this happens). Therefore, to be more reliable, we must collaborate to establish reliable DID (Decentralized ID) in all AI. For example, eventually, when anyone asks ChatGPT, it should immediately tell you its wallet address. Then we can verify it. Of course, this is just an assumption because the cryptographic algorithms corresponding to Ethereum wallet addresses (EOA) have been proven to be resistant to quantum attacks...
In this way, PoV can reward not just one type of smart commons. So how should smart commons be categorized?
Ultimately, we borrowed common methods from Unix operating systems and Windows:
- The classification of Smart Commons is reflected in the extensions of the Valuation Tokens.
- The naming of Valuation Tokens draws inspiration from computer operating systems, splitting into two parts with a dot (".").
- The naming rule for Valuation Tokens is "XXXX.extension". For example: UL.eip (indicating its Smart Common is an EIP) or ALOHA.ai (indicating it is an AI project 😂). The extension is recommended to be in lowercase to make the preceding name stand out. Anyone can freely set the extension for their Smart Common—this is a decentralized naming convention. Of course, if someone has already made a flawless naming for a category, it is hoped that subsequent developers will follow it.
- The filename is case-insensitive, but the frontend will display it with the intended case.
- The extension cannot be empty.
- Extensions can only be added, not deleted.
- Modifying an extension could mean adding a new one or selecting another existing extension.
- Whoever proposes the modification is migrating his smart common—if a Smart Common developer decides to modify the extension of their Valuation Token, they are effectively adding a new extension or migrating to another existing one, thereby classifying their Smart Common under the new category. The original extension is not deleted. This way, other Smart Commons that voluntarily joined the original category (original extension) remain unaffected.
- Adjustments to extensions must be voted on through proposals.
- In the frontend, existing extensions automatically become selectable when users fill in the form. Once selected, the description of the extension will appear. This helps avoid using the same extension for different categories.
- The naming of extensions is decentralized with no restrictions, but for better memorability, users are advised to use simple and memorable names, preferably using letters and numbers. Generally, it is not recommended to include special characters in the filename.
- Details
Preparation
Dear developers,
This article is not a Solidity programming tutorial, but rather a suggestion aimed at maximizing the opportunities for Smart Common (public dApp) developers to earn awards.
Before reading this suggestion, be sure to understand DAism thoroughly to fully grasp this guide. Oh yeah, every developer of dApps and every author of EIPs had better read this article.
Minimum Requirements:
📖 DAism Whitepaper
🤖 Remember: You don't need to team up with others; your best partner is called AI!
Good Luck!
- Details
Our proposed EIP-2569 was submitted in 2019, in which we proposal to save SVG images on Ethereum. During the past years quite a few projects actually have already used similar ways to save SVG image files on Ethereum such as the avartars (https://avastars.io/) , Uniswap V3 (which saves LP images as SVG files on Ethereum) , cryptopunks (which recently announced that all punk images have been saved as SVG files on Ethereum: https://www.larvalabs.com/
- Details
This standard covers some situations that the ERC-20 standard and ERC-1155 standard can hardly handle. It allows multiple types of fungible tokens to be sent to multiple receiving addresses via our proposed interface transferBatchMul
and allows multiple types of fungible tokens to be sent from multiple sending addresses to multiple receiving addresses via our proposed interface transferFromBatchMul
. This standard greatly reduces the gas consumption in transactions of multiple types of fungible tokens. In addition the standard allows both setting of an approval for a single token via an interface approve(uint256 id,address spender, uint256 amount)
and setting of approvals uniformly for all types of tokens via an interface approve(address spender,bool _status)
.
Read more about EIP-3712: Standard for Multiple Types of Fungible-Tokens.
You can also read the Chinese version on this website.