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
Mastering Ethereum: Ethereum Clients
今日はMastering Etherumのなかのethereum clientsの項目を読んだ。
この章も特に目新しいことはなかったが、復習には良かった。
書いてある内容としては
- Ethereum Networks
Full Node Advantages and Disadvantages Public Testnet Advantages and Disadvantages Local Instance (ganache) Advantages and Disadvantag Running an Ethereum client Hardware Requirements for a Full Node Minimum Requirements: Recommended Specifications: Software Requirements for Building and Running a Client (Node) Parity Go-Ethereum (Geth) The First Synchronization of Ethereum-based Blockchains JSON-RPC Interface Remote Ethereum Clients Mobile (Smartphone) Wallets Browser wallets Refernces:EIP-161: http://eips.ethereum.org/EIPS/eip-161
上記のようになっている。
基本的には
どういうイーサリウムクライアントが存在しているか
フルノード、テストネット、プライベートネットの特徴
それぞれのメリット、デメリット
parity/gethをはじめとしたクライアントの説明と概要説明、メリットデメリット
どのようなファイル形式で扱われるか。
起動方法
remote client
mobile wallet
browserwallet
などを簡潔に説明している章だった。
基本は
EIP-161: http://eips.ethereum.org/EIPS/eip-161
で見れる。
day4:EIP1047,1051,1052
eip-1047:Token Metadata JSON Schema
- summary
A standard interface for token metadata
ERC20とERC721と区別なくmetadataの統一
- specificaiton
{
"title": "Asset Metadata",
"type": "object",
"properties": {
"name": {
"type": "string",
"description": "Identifies the asset to which this token represents",
},
"description": {
"type": "string",
"description": "Describes the asset to which this token represents",
},
"image": {
"type": "string",
"description": "A URI pointing to a resource with mime type image/* representing the asset to which this token represents. Consider making any images at a width between 320 and 1080 pixels and aspect ratio between 1.91:1 and 4:5 inclusive.",
}
}
}
- rationale
One JSON schema standard will allow for simpler maintenance of this critical schema
メンテナンスが楽になる。
- source
EIPs/eip-1047.md at master · ethereum/EIPs · GitHub
eip-1051:Overflow checking for the EVM
- summary
This EIP adds overflow checking for EVM arithmetic operations, and two new opcodes that check and clear the overflow flags.
overflow検知とopcodeの追加
speculation
Two new flags are added to the EVM state: overflow (ovf) and signed overflow (sovf).
rationale
Rationale Any change to implement overflow protection needs to preserve behaviour of existing contracts, which precludes many changes to the arithmetic operations themselves. One option would be to provide an opcode that enables overflow protection, causing a throw or revert if an overflow happens. However, this limits the manner in which overflows can be handled.
現状のコントラクトのoverflowを防ぐ方法に当たる変更はかなり大きなものとなってしまう。
そのため、解決策としてはいくつか考えられる。
一つ目のオプションはoverflow protectionを可能とするopcodeを提供することである。それは、もしoverflowが起こったら、それを放り出すか、revertする考えである。
しかし、その方法にはoverflowが行われる方法に対しての手法としては限界がある。
Instead, we replicate functionality from real world CPUs, which typically implement 'carry' and 'overflow' flags.
代わりにreal world CPUsから複製するという感が型もある。それはcarryとoverflowのフラグを立てるものである。
Separate flags for signed and unsigned overflow are necessary due to the fact that a signed overflow may not result in an unsigned overflow.
signed and unsignedに対してのフラグを切り分けることは重要である。それはsigned overflowはunsigned overflowという結果にはならないという事実のためである。
- source
EIPs/eip-1051.md at master · ethereum/EIPs · GitHub
EIP-1051: Arithmetic overflow detection for the EVM - EIPs - Fellowship of Ethereum Magicians
eip-1052:EXTCODEHASH opcode
abstract
This EIP specifies a new opcode, which returns the keccak256 hash of a contract's code.
motivation
Many contracts need to perform checks on a contract's bytecode, but do not necessarily need the bytecode itself. For instance, a contract may want to check if another contract's bytecode is one of a set of permitted implementations, or it may perform analyses on code and whitelist any contract with matching bytecode if the analysis passes.
Contracts can presently do this using the EXTCODECOPY opcode, but this is expensive, especially for large contracts, in cases where only the hash is required. As a result, we propose a new opcode, EXTCODEHASH, which returns the keccak256 hash of a contract's bytecode.
とりあえず、既存のEXTCODECOPYというコードがコスパがあまり良くなくて、容量をめちゃくちゃ食うので、新たにEXTCODEHASHというopcodeを提案したという話。
- speculation
A new opcode, EXTCODEHASH, is introduced, with number 0x3F. The EXTCODEHASH takes one argument from the stack, zeros the first 96 bits and pushes to the stack the keccak256 hash of the code of the account at the address being the remaining 160 bits.
In case the account does not exist 0 is pushed to the stack.
In case the account does not have code the keccak256 hash of empty data (i.e. c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470) is pushed to the stack.
The gas cost of the EXTCODEHASH is 400.
rationale 上述した通り、既存の方法ではgascostが大きすぎる。
source
Ethereumのアドレス生成アルゴリズム Keccak-256 Online
keccak - How does the Keccak256 hash function work? - Ethereum Stack Exchange
day3:EIP1014,1015,1046
EIP1014:Skinny CREATE2
イーサリアムステートチャネルを追加するためのもの
simply and request to refer to SHA-3 as keccak256.
Adds a new opcode at 0xf5, which takes 4 stack arguments: endowment, memory_start, memory_length, salt. Behaves identically to CREATE, except using sha3(msg.sender ++ salt ++ init_code)[12:] instead of the usual sender-and-nonce-hash as the address where the contract is initialized at.
- source
EIP-1014: Use keccak256 name instead of sha3 by chfast · Pull Request #1247 · ethereum/EIPs · GitHub
EIP1015:Configurable On Chain Issuance
正直よくわかってない。多分議題がとても多いので方針を決めようってことなんだろうけど、あとでもう一度読む。
- simple summary
This EIP changes the block reward step by instead of setting it to be hard coded on the clients and to be given to the miner/validator etherbase, it should instead go to an address decided by an on-chain contract, with hard limits on how it would be issued (six month lock-in; issuance can only decrease or be mantained, but not increase;). A decision method is suggested but not essential to the notion of this EIP. This would not be a generic governance solution, which is a much broader and harder topic, would not affect technical upgrade decisions or other hard forks, but seen as a forum to attempt to prevent contentious hard forks that can be solved with the issuance.
EIPs/eip-1015.md at master · ethereum/EIPs · GitHub
EIP1046:ERC20 Metadata Extension
simple summary
Optionally extend ERC20 token interface to support the same metadata standard as ERC721 tokens.
motivation
The ERC721 standard was created to support the creation of perfectly unique, 1-of-1, non-divisible tokens known as "non-fungible tokens".
The initial use case for the ERC721 standard was to support the creation of crypto-collectibles and gaming assets, initially for the "Crypto Kitties" collectibles game. The success of Crypto Kitties catalyzed significant application development to support the display of ERC721 assets using the tokenURI metadata parameter.
However, not all crypto-collectibles and gaming assets need to be unique and non-fungible. Gaming assets (items, weapons, characters), crypto-artworks with non-unique "prints", and more will function more like traditional ERC20 tokens with a fungible supply. Many applications such as wallets, exchanges, games, etc. will want to support both fungible and non-fungible assets containing similar metadata. This proposal will extend the ERC20 standard to optionally include a nearly identical tokenURI parameter supporting the same JSON metadata schema as the ERC721 standard.
cryptkittiesは確かにnon-fungible tokenとしてユニークさを持って、tokenURL metadata parameterで管理されることによって価値を持ったが、全てのcrypto-collectible and gaming assetsが必ずしもunique and non-fungibleである必要もない。erc20とerc721をなるべく似たような規格にすることによって、クリプトネットワークの連携しやすさを高めた方が良いのではという提案(な気がする)。
- rationale
This proposal will make adding metadata to ERC20 tokens straightforward for developers with minimal-to-no disruption to the overall ecosystem. By using the same parameter name and by consolidating the underlying Token JSON Metadata Standard, developers will confidently understand how to add and interpret token metadata between ERC20 and ERC721 tokens.
まあ普通に考えて、json形式で書いた方が開発者も混乱しないし、あとで見たときの後方互換性も高まるし統一した方が良いんでない？っていう提案。
Rare Art Labs (WIP) Open Zeppelin (WIP) とかで試す予定.
- source
mastering ethereum
- introductionの項目
we’ve set up a wallet using MetaMask and we’ve funded it using a faucet on the Ropsten Test Network. We received ether into our wallet’s Ethereum address.
主に
- EOAとcontractに関して
- walletの説明(walletとはworld computer/evmの入り口、mobile, desktop, web- base etc...)
- metamaskの説明
- 実際にremix上でfaucetやコントラクトの作成(ropsten)
導入部分なので特に目新しいことはなかったけど、基礎の復習としてはよかったかもしれない。
トークン
今日やったこと
- erc20のトークン発行とmyetherwalletとの接続と送受金。
- erc721のdapps作成、画像変更、画像生成アルゴリズムの作成と実装
- mvp（minimalvaiableplasma）の動作確認と、関連プロジェクトの確認、vyperでのmvpを取り込んだプロトコルの開発
erc20に関して
自己発行のholderの調整に関して知りたい
erc721に関して
横スライドのカテゴリー分岐画面（クライアント部分）の実装と、ウェブ側をデプロイする際の仕組み、ciツールの取り込みとテストコードの実装。
mvp(minimal viable plasma)に関して
基本はgoとpythonを使うことが多そうなのでgkeかdockerのコンテナ方式とciで仕組み化したい。また、デプロイ時にはconfigファイルのセッティングとweb側のデプロイまでの仕組みはテンプレ化できそうなので形を作っておく。クライアント部分に関してはreact/reduxは正直完全にマスターしているとは言い難いのでもう少し時間を費やして、実装しながらなじませていく。
やりたいこと
dapps に関してはあと数個作って、実装までのテンプレ的なフローを作ったらある程度はそこで止めといても良い気がする。dexみたいに関連プロトコル繋げる拡張可能性のあるものは作っておくが。web側のデプロイはgkeベースにしても良いがいかんせんお金がかかるのでgaeにするか（コストどうなんだろ？）、もしくは普通にサーバー借りてnginxかApacheで組むか、firebase でも使うか、netlify見ないなの使うかプロトみたいな軽いやつデプロイ用と長期でデプロイするので従量課金か定額か、自由度が効くか、固定化されたやつか試しながら考える。
仕組み化したら、plasmaやcosmosやlightning/Handshake/parity/casperあたりのプロトコルやセキュリティトークンの設計や実装、スマコンのセキュリティ部分などもっとコアなところにコミットしつつ、OSSの方中心にシフトしていきたい。
day2:EIP1010,1011,1013
eip-1010: Uniformity Between 0xAb5801a7D398351b8bE11C439e05C5B3259aeC9B and 0x15E55EF43efA8348dDaeAa455F16C43B64917e3c
This document proposes to improve the uniformity of ether distribution between wallet address 0xAb5801a7D398351b8bE11C439e05C5B3259aeC9B and wallet address 0x15E55EF43efA8348dDaeAa455F16C43B64917e3c which are currently experiencing a significant non-uniformity.
トランザクションに一貫性を持たせて、ethereumネットワーク全体の統一と、中央集権化せず、非中央分散型の思想を守るために提案
EIPs/eip-1010.md at master · ethereum/EIPs · GitHub
eip-1011: Hybrid Casper FFG
Specification of the first step to transition Ethereum main net from Proof of Work (PoW) to Proof of Stake (PoS). The resulting consensus model is a PoW/PoS hybrid.
This EIP specifies a hybrid PoW/PoS consensus model for Ethereum main net. Existing PoW mechanics are used for new block creation, and a novel PoS mechanism called Casper the Friendly Finality Gadget (FFG) is layered on top using a smart contract.
Through the use of Ether deposits, slashing conditions, and a modified fork choice, FFG allows the underlying PoW blockchain to be finalized. As network security is greatly shifted from PoW to PoS, PoW block rewards are reduced.
This EIP does not contain safety and liveness proofs or validator implementation details, but these can be found in the Casper FFG paper and Validator Implementation Guide respectively.
ethereumのコンセンサスアルゴリズムをpowからpow/posのハイブリッド型にする提案。 Existing PoW mechanics are used for new block creationの上にcasperFFGと呼ばれるposアルゴリズムを取り込んでその上でスマートコントラクト を実装運用することを目標とする。
Glossary
- epoch: The span of blocks between checkpoints. Epochs are numbered starting at the hybrid casper fork, incrementing by one at the start of each epoch.
- finality: The point at which a block has been decided upon by a client to never revert. Proof of Work does not have the concept of finality, only of further deep block confirmations.
- checkpoint: The block/hash under consideration for finality for a given epoch. This block is the last block of the previous epoch. Rather than dealing with every block, Casper FFG only considers checkpoints for finalization. When a checkpoint is explicitly finalized, all ancestor blocks of the checkpoint are implicitly finalized.
- validator: A participant in the Casper FFG consensus that has deposited ether in the casper contract and has the responsibility to vote and finalize checkpoints.
- validator set: The set of validators in the casper contract at any given time.
- dynasty: The number of finalized checkpoints in the chain from root to the parent of a block. The dynasty is used to define when a validator starts and ends validating. The current dynasty only increments when a checkpoint is finalized as opposed to epoch numbers that increment regardless of finality.
- slash: The burning of some amount of a validator's deposit along with an immediate logout from the validator set. Slashing occurs when a validator signs two conflicting vote messages that violate a slashing condition. For an in-depth discussion of slashing conditions, see the Casper FFG Paper.
Rationale
Casper FFG solves problems such as "Nothing at Stake" and "Long Range Attacks" through requiring validators to post slashable deposits and through defining economic finality.
source
EIPs/eip-1011.md at master · ethereum/EIPs · GitHub
eip-1013: Hardfork Meta: Constantinople
This meta-EIP specifies the changes included in the Ethereum hardfork named Constantinople. Constantinopleという名のハードフォークを含んだ変更部分の具体化
specification
Codename: Constantinople Aliases: Metropolis/Constantinople, Metropolis part 2 Activation: Block >= TBD on the Ethereum mainnet Block >= TBD on the Ropsten testnet Included EIPs: EIP 145: Bitwise shifting instructions in EVM EIP 210: Blockhash refactoring EIP 1014: Skinny CREATE2 EIP 1052: EXTCODEHASH Opcode EIP 1087: Net gas metering for SSTORE operations TBD: Ice-age delay
なんか、Constantinopleに関してまとめた提案のリストみたいな感じらしい。
