day5:EIP1057,1062,1066
eip1057:ProgPoW, a Programmatic Proof-of-Work
- short summary
The following is a proposal for an alternate proof-of-work algorithm - “ProgPoW” - tuned for commodity hardware in order to close the efficiency gap available to specialized ASICs.
powを代替するASICなどのハードウェアによるギャップを埋めるためのコンセンサスアルゴリズム。
- motivation
Until Ethereum transitions to a pure proof-of-stake model, proof-of-work will continue to be a part of the security of the network - whether it’s adapted into a hybrid model (as is the case of Casper FFG), or adopted by a hard fork. Ethash allows for the creation of an ASIC that is roughly twice as efficient as a commodity GPU. Ethash’s memory accesses are paired with a very small amount of fixed compute. Most of a GPU’s capacity and complexity sits idle, wasting power, while waiting for DRAM accesses. A specialized ASIC can implement a much smaller (and cheaper) compute engine that burns much less power. As miner rewards are reduced with Casper FFG, it will remain profitable to mine on a specialized ASIC long after GPUs have exited the network. This will make it easier for an entity that has access to private ASICs to stage a 51% attack on the Ethereum network.
casperFFGによってPOSに移行するまでにPOWによって、Ethereum networkのセキュリティを守らないといけない。しかし、現状のようにマイニング特化したASICの存在は51%アタックの可能性も高めるし、commodity cpu/gpuの報酬も減るので、インセンティブ的にも、セキュリティ的にもよくない。CasperFFGによるPOSへの移行、またはhard forkを用いずとも仕組みをうまく回すために今回のアルゴリズムの提案をする。
- specification
使用に関してはEIPs/eip-1057.md at master · ethereum/EIPs · GitHub を見た方が早い
test
Model/Hashrate (MH/s)
RX580 9.4 Vega56 16.6 Vega64 18.7 GTX1070Ti 13.1 GTX1080 14.9 GTX1080Ti 21.8
eip-1062:Formalize IPFS hash into ENS(Ethereum Name Service) resolver
- simple summary
To specify the mapping protocol between resources stored on IPFS and ENS(Ethereum Naming Service).
- motivation
To build fully decentralized web service, it’s necessary to have a decentralized file storage system. Here comes the IPFS, for three following advantages : Address large amounts of data, and has unique cryptographic hash for every record. Since IPFS is also based on peer to peer network, it can be really helpful to deliver large amounts of data to users, with safer way and lower the millions of cost for the bandwidth. IPFS stores files in high efficient way via tracking version history for every file, and removing the duplications across the network. Those features makes perfect match for integrating into ENS, and these make users can easily access content through ENS, and show up in the normal browser.
完全な分散化されたネットワークを構築する上で、分散化されたデータストレージシステムが必要になってくる。IPFSのような分散ハッシュシステムにはいくつかの利点がある。
より多くのデータにアドレスでき、データをハッシュ化してユニークなものとして扱える。
IPFSはp2pの元となっているので、より大容量のデータをより安全にデリバリーできる。そしてそれは帯域コストを何百万も下げうる。
IPFSはストレージデータに対して、あらゆるサービスにアクセスする最も効率的な方法。また、複製リスクもなくす。
以上の理由から、IPFSのような分散ハッシュシステムはENSのようなものとつながり合うことによって、役割を最大化することができる。
- specification
The condition now is that the IPFS file fingerprint using base58 and in the meantime, the Ethereum uses hex in API to encode the binary data. So that need a way to process the condition requires not only we need to transfer from IPFS to Ethereum, but also need to convert it back. To solve these requirements, we can use binary buffer bridging that gap. When mapping the IPFS base58 string to ENS resolver, first we convert the Base58 to binary buffer, turn the buffer to hex encrypted format, and save to the contract. Once we want to get the IPFS resources address represented by the specific ENS, we can first find the mapping information stored as hex format before, extract the hex format to binary buffer, and finally turn that to IPFS Base58 address string.
しばらくの間はIPFSはbase58を用いたfingerprintをベースにする。ethereumはバイナリーデータをエンコードするapiのhexを用いる。しかし、コンバートし返すことも必要となってくる。
Base58をbinary bufferに変換。hexをencrypted formatに帰る。
IPFSリソースを特定のENSによってアドレスしたい時になって初めて、ためていたデータをhex formatにしてhex formatをbinary bufferにする。
そして最終的にはbinary bufferをIPFSにBase58 address stringにする。
implementation
EIPs/eip-1062.md at master · ethereum/EIPs · GitHub
eip-1066:Status Codes
- simple summary
Broadly applicable status codes for Ethereum smart contracts.
- abstract
This standard outlines a common set of Ethereum status codes (ESC) in the same vein as HTTP statuses. This provides a shared set of signals to allow smart contracts to react to situations autonomously, expose localized error messages to users, and so on. The current state of the art is to either revert and require human intervention, or return a Boolean pass/fail status. Status codes are similar-but-orthogonal to reverting with a reason, but aimed at automation and translation. As is the case with HTTP, having a standard set of known codes has many benefits for developers. They remove friction from needing to develop your own schemes for every contract, makes inter-contract automation easier, and makes it easier to broadly understand which of the finite states your request produced. Importantly, it makes it much easier to distinguish between expected errors states, and truly exceptional conditions that require halting execution.
httpの時は共通規格を決めつつ開発していたので、必要以上に考えのズレなど起こさず広げることができた。ethereumも同じようにしたら良いのでは？という提案。
motivation
Autonomy
Semantic Density
User Feedback
More than Pass/Fail
specification
EIPs/eip-1066.md at master · ethereum/EIPs · GitHub 見ると図示化されていてわかりやすい
- dex
0x03 = Waiting
0x31 = Other Party (ie: not you) Agreed
0x41 = Available
0x43 = Not Yet Available
Exchange
AwesomeCoin DEX TraderBot
+ + +
| | buy(AwesomeCoin) |
| | <------------------------+
| buy() | |
| <---------------------+ |
| | |
| Status [0x43] | |
+---------------------> | Status [0x43] |
| +------------------------> |
| | |
| | isDoneYet() |
| | <------------------------+
| | |
| | Status [0x43] |
| +------------------------> |
| | |
| | |
| Status [0x41] | |
+---------------------> | |
| | |
| buy() | |
| <---------------------+ |
| | |
| | |
| Status [0x31] | |
+---------------------> | Status [0x31] |
| +------------------------> |
| | |
| | |
| | |
| | |
+ + +
0x01 = Generic Success
0x10 = Disallowed
0x11 = Allowed
Token Validation
Buyer RegulatedToken TokenValidator IDChecker SpendLimiter
+ + + + +
| buy() | | | |
+------------------------> | check() | | |
| +-----------------------> | check() | |
| | +-----------------------> | |
| | | | |
| | | Status [0x10] | |
| | Status [0x10] | <-----------------------+ |
| revert() | <-----------------------+ | |
| <------------------------+ | | |
| | | | |
+---------------------------+ | | | |
| | | | | |
| Updates ID with provider | | | | |
| | | | | |
+---------------------------+ | | | |
| | | | |
| buy() | | | |
+------------------------> | check() | | |
| +-----------------------> | check() | |
| | +-----------------------> | |
| | | | |
| | | Status [0x11] | |
| | | <-----------------------+ |
| | | | |
| | | | check() |
| | +-------------------------------------------> |
| | | | |
| | | | Status [0x11] |
| | Status [0x11] | <-------------------------------------------+
| Status [0x01] | <-----------------------+ | |
| <------------------------+ | | |
| | | | |
| | | | |
| | | | |
+ + + + +
rationale
encoding
Multiple Returns
Human Readable
Extensibility
EVM codes
Empty space
Nibble Order
Implementation
GitHub - expede/ethereum-status-codes: Status codes for Ethereum smart contracts
- semantic
セマンティックウェブ | WWW用語辞典 | IT用語辞典 | 日立ソリューションズ EIPs/eip-1066.md at master · ethereum/EIPs · GitHub
