├── Contract-metadata.md ├── [日本語版]ホーム.md ├── Which-Client?.md ├── images ├── natspec1.png ├── natspec2.png ├── natspec3.png ├── natspec4.png └── natspec5.png ├── ethereum.com.md ├── Ethereum-akan-naik-karena-teknologi--terus-dikembangkan-dan-ditingkatkan.md ├── [Persian]-Ethereum-TOC.md ├── RPC-Testing.md ├── drafts └── [english]-patricia-tree-draft.md ├── Todo-before-alpha.md ├── Exchange-Integration.md ├── Template:-This-Week-in-Ethereum-w-YY.md ├── [中文]-以太坊Wiki目录.md ├── [Chinese]-Ethereum-白皮書.md ├── pages ├── ethereum-toc │ ├── [chinese]-ethereum-toc.md │ ├── [german]-ethereum-toc.md │ ├── [spanish]-ethereum-toc.md │ └── [italian]-ethereum-toc.md ├── white-paper │ └── [persian]-white-paper.md └── rlp │ ├── [chinese]-rlp.md │ ├── [japanese]-rlp.md │ ├── [romanian]-rlp.md │ ├── [english]-rlp.md │ └── [german]-rlp.md ├── Default-Extra-Data-Standard.md ├── Node-discovery-protocol.md ├── Useful-Ðapp-Patterns.md ├── Solidity-Collections.md ├── Blockchain-import-and-export-instructions.md ├── IPv6.md ├── [Japanese]-Ethereum-TOC.md ├── eπ-Programme.md ├── Solidity-Tutorial.md ├── sendTransaction-return-value-proposal.md ├── Gitter-Channels.md ├── Adaptive-Peer-Time.md ├── Bad-Chain-Canary.md ├── Serpent_3.0.md ├── enode-url-format.md ├── NewBlock-Message.md ├── Dapp-Developer-Resources.md ├── web.js-0.9.md ├── [Romanian]-Cuprins.md ├── Deterministic_Wallet_Spec.md ├── Proposal:-BlockHashesFromNumbers.md ├── Proposal:-NewBlockHashes.md ├── Geth-Dapp-loading-proposal.md ├── Whisper-Wire-Protocol.md ├── Ethash-DAG.md ├── NatSpec-Determination.md ├── Ethash-DAG-Disk-Storage-Format.md ├── Security-Issue-Process.md ├── .gitignore ├── [Japenese]-Ethereum-TOC.md ├── Tags-for-Solidity-in-code-documentation.md ├── [Chinese]-Ethereum-TOC.md ├── Javascript-Development-Deficiencies.md ├── Poll-for-token-proposal-EIP-20.md ├── Brain-Wallet.md ├── Parallel-Block-Downloads.md ├── Mix-improvement-proposal.md ├── Ethash-C-API.md ├── newBlockFilter-Improvement-Proposal.md ├── First-steps-with-ethereum-JSON-RPC.md ├── EVM-JIT-Binary-Interface.md ├── شركة-المنارة.md ├── Natspec-Example.md ├── This Week In Ethereum 47.2014.md ├── [中文]-网络状态.md ├── [中文]-RLP.md ├── Home.md ├── URL-Hint-Protocol.md ├── [Japanese]--License.md ├── Licensing.md ├── Client-Version-Strings.md ├── JSON-RPC-Error-Codes-Improvement-Proposal.md ├── Layers.md ├── [Romanian]-Layers.md ├── Whisper-PoC-2-Wire-Protocol.md ├── Solidity-Changelog.md ├── [Italian]-Impostare-il-proprio-ambiente-di-sviluppo-Ethereum.md ├── Open-positions-&-Schemes.md ├── Ethash-Design-Rationale.md ├── Morden.md ├── Solidity-standard-library.md ├── _Sidebar.md ├── Proposal:-Transaction-Proxy-Hooks.md ├── Proposal:-Reversion-Notification.md ├── libp2p-Whitepaper.md ├── Network-Status.md ├── Kademlia-Peer-Selection.md ├── Proposal:-Extend-GetBlockHashes-with-target-hash.md ├── Swarm-Hash.md ├── [Romanian]-Limbajul-de-programare-Serpent.md ├── Adaptive-Message-IDs.md ├── Clearinghouse.md ├── ÐΞVp2p-Wire-Protocol.md ├── [Japanese]-Whisper-（ウィスパー）.md ├── Generalized_Merkle_DHT.md └── Standardized_Contract_APIs.md /Contract-metadata.md: -------------------------------------------------------------------------------- 1 | ( ͡° ʖ̯ ͡°) -------------------------------------------------------------------------------- /[日本語版]ホーム.md: -------------------------------------------------------------------------------- 1 | # Ethereum Wikiへようこそ -------------------------------------------------------------------------------- /Which-Client?.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Which Client? 3 | category: 4 | --- 5 | 6 | ----- -------------------------------------------------------------------------------- /images/natspec1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ethereumproject/wiki/HEAD/images/natspec1.png -------------------------------------------------------------------------------- /images/natspec2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ethereumproject/wiki/HEAD/images/natspec2.png -------------------------------------------------------------------------------- /images/natspec3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ethereumproject/wiki/HEAD/images/natspec3.png -------------------------------------------------------------------------------- /images/natspec4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ethereumproject/wiki/HEAD/images/natspec4.png -------------------------------------------------------------------------------- /images/natspec5.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ethereumproject/wiki/HEAD/images/natspec5.png -------------------------------------------------------------------------------- /ethereum.com.md: -------------------------------------------------------------------------------- 1 | #ethereum.com good money eye digital 2 | # hello world good dompet money digital 3 | Status good web,aplikasi,seluler play 4 | ,#pay and seller and buyer coin digital -------------------------------------------------------------------------------- /Ethereum-akan-naik-karena-teknologi--terus-dikembangkan-dan-ditingkatkan.md: -------------------------------------------------------------------------------- 1 | Ethereum bagus untuk penyimpanan dan pertambangan karena teknologi mendukung dan terus 2 | Menghasilkan dan memuaskan pengguna nya -------------------------------------------------------------------------------- /[Persian]-Ethereum-TOC.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Ethereum TOC 3 | category: 4 | --- 5 | 6 | ### به اتریوم، نسل بعدی قراردادهای هوشمند و نرم افزارهای غیر متمرکز خوش آمدید 7 | 8 | [برگ سفید](./%5BPersian%5D-White-Paper) -------------------------------------------------------------------------------- /RPC-Testing.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: RPC Testing 3 | category: 4 | --- 5 | 6 | ``` 7 | { 8 | blockchain: [ 9 | { 10 | difficulty: 1024, 11 | transactions: [ 12 | ... 13 | ] 14 | }, 15 | ] 16 | } 17 | ``` -------------------------------------------------------------------------------- /drafts/[english]-patricia-tree-draft.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Patricia Tree 3 | category: 4 | --- 5 | 6 | The best known tutorial/explanation of the ethereum patricia tree is here: 7 | https://easythereentropy.wordpress.com/2014/06/04/understanding-the-ethereum-trie/ -------------------------------------------------------------------------------- /Todo-before-alpha.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: TODO Before Alpha 3 | category: 4 | --- 5 | 6 | ## Etereum P2P sub-protocol 7 | 8 | * Fix numbering in [Wire](./Ethereum-Wire-Protocol) protocol. 9 | * Add `gasprice` message 10 | * `[[id, price], [id, price], ...]` -------------------------------------------------------------------------------- /Exchange-Integration.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Exchange Integration 3 | category: 4 | --- 5 | 6 | ## Overview 7 | 8 | TODO 9 | 10 | ## Reference implementation 11 | 12 | TODO: Design/documentation for implementation 13 | 14 | https://github.com/debris/eth-exchange 15 | -------------------------------------------------------------------------------- /Template:-This-Week-in-Ethereum-w-YY.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: This Week in Ethereum Template 3 | category: 4 | --- 5 | 6 | ###Current Status 7 | 8 | ### Protocol 9 | 10 | ## Clients 11 | 12 | ### AlethZero 13 | 14 | ### Mist 15 | 16 | ###pyethereum 17 | 18 | ##Projects 19 | 20 | ##People 21 | 22 | ##In the Media 23 | 24 | ##Upcoming Events 25 | 26 | ### Meetups 27 | -------------------------------------------------------------------------------- /[中文]-以太坊Wiki目录.md: -------------------------------------------------------------------------------- 1 | 中文读者可以在[以太坊爱好者社区](http://ethfans.org)获知最新信息。 2 | 3 | 白皮书：[以太坊（Ethereum ）:下一代智能合约和去中心化应用平台](./White-Paper-%5BChinese%5D) 4 | 5 | [Serpent语言指南](./%5B%E4%B8%AD%E6%96%87%5D-Serpent%E6%8C%87%E5%8D%97) 6 | 7 | [以太坊开发计划](./%E4%BB%A5%E5%A4%AA%E5%9D%8A%E5%BC%80%E5%8F%91%E8%AE%A1%E5%88%92) 8 | 9 | [术语表](./%E6%9C%AF%E8%AF%AD%E8%A1%A8) 10 | 11 | [网络状态监控](./Network-Status-%28Chinese%29) -------------------------------------------------------------------------------- /[Chinese]-Ethereum-白皮書.md: -------------------------------------------------------------------------------- 1 | # 次世代的智能合約與去中心化應用程式平台 2 | 3 | 中本聰在2009年的Bitcoin的發展往往被喻為貨幣和貨幣激進的發展，作為其同時具有無實體資產背書或“內在價值”，並沒有集中發行人或控制者數字資產的第一個例子。然而，另一種，可以說更重要的是，比特幣實驗的一部分是基於區塊鏈技術的分佈式共識工具，研究的注意迅速開始轉移到比特幣的另一層面。普遍提及區塊鏈技術的其他應用包括使用區塊鏈代表：客製化的貨幣和金融工具（“有色幣”）、底層物理設備所有權的（“智能財產”）、不可替代資產，如域名（“Namecoin”）、以及更複雜的應用，數字資產直接被程式實作的任意規則控制的（“智能合同”），甚至基於區塊鏈的“分權自治組織”（DAO）。Ethereum 意圖提供成熟的圖靈完備編程語言區塊鏈， 可用於創建能編碼任意狀態轉換函數的「合約」。讓使用者能創建任何上述系統，以及許多其它我們還沒有想到，僅僅通過幾行代碼所能撰寫的應用。 -------------------------------------------------------------------------------- /pages/ethereum-toc/[chinese]-ethereum-toc.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Ethereum TOC 3 | category: 4 | --- 5 | 6 | 中文读者可以在以太坊中文社区( www.1tf.org )获知最新信息。 7 | 8 | 白皮书：[以太坊（Ethereum ）:下一代智能合约和去中心化应用平台](./White-Paper-%5BChinese%5D) 9 | 10 | [Serpent语言指南](./%5B%E4%B8%AD%E6%96%87%5D-Serpent%E6%8C%87%E5%8D%97) 11 | 12 | [以太坊开发计划](./%E4%BB%A5%E5%A4%AA%E5%9D%8A%E5%BC%80%E5%8F%91%E8%AE%A1%E5%88%92) 13 | 14 | [术语表](./%E6%9C%AF%E8%AF%AD%E8%A1%A8) 15 | 16 | [网络状态监控](./Network-Status-%28Chinese%29) -------------------------------------------------------------------------------- /Default-Extra-Data-Standard.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Extra Data 3 | category: 4 | --- 5 | 6 | Implementations are encouraged to follow this protocol for populating the `extraData` field of mined blocks. 7 | 8 | `extraData` should be an RLP list whose first element is a version identifier encoded as a canonical RLP positive integer. All other items in the list are determined by the version ID. 9 | 10 | `[` version: `P`, ... `]` 11 | 12 | ### Version 0 13 | 14 | `[` version: `P`, clientIdentity: `B` `]` 15 | 16 | One further argument, a raw representation of a string to identify the client (this would usually be a shortened form of the client identifier as returned by the JSON RPC's `web3_clientVersion`). 17 | -------------------------------------------------------------------------------- /Node-discovery-protocol.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Node Discovery Protocol 3 | category: 4 | --- 5 | 6 | In a nutshell: 7 | * Aimed at discovering _RLPx nodes_ to connect to 8 | * UDP-based RPC protocol ([kademlia](https://en.wikipedia.org/wiki/Kademlia)-like) 9 | * Defines 4 packet types: _ping_, _pong_, _findnode_ and _neighbors_ 10 | 11 | See details at either: 12 | * [devp2p](https://github.com/ethereumproject/devp2p) repository's [node discovery protocol](https://github.com/ethereumproject/devp2p/blob/master/rlpx.md) page 13 | * [go-ethereum](https://github.com/ethereumproject/go-ethereum) repository's [node discovery protocol](https://github.com/ethereumproject/go-ethereum/wiki/RLPx-----Node-Discovery-Protocol) page -------------------------------------------------------------------------------- /Useful-Ðapp-Patterns.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Useful DAPP Patterns 3 | category: 4 | --- 5 | 6 | The following page is a collection of useful patterns, Ðapps can use, such as talking to the blockchain reliably. 7 | 8 | The example patterns can possibly change, so don't rely fully on them as of yet. 9 | 10 | ## Examples 11 | 12 | - 3 ways of instantiating web3: 13 | https://gist.github.com/frozeman/fbc7465d0b0e6c1c4c23 14 | 15 | - Contract deployment by code: 16 | (Outdated, use `web3.contract(abiArray).new({}, function(e, res){...})`) 17 | https://gist.github.com/frozeman/655a9325a93ac198416e 18 | 19 | - Test a contract transaction with a `call` before actually sending: 20 | https://gist.github.com/ethers/2d8dfaaf7f7a2a9e4eaa -------------------------------------------------------------------------------- /Solidity-Collections.md: -------------------------------------------------------------------------------- 1 | This is a list of collections of Solidity code. Please add to this list, preserving alphabetical order. 2 | 3 | * [dapp-bin/library](https://github.com/ethereum/dapp-bin/tree/master/library): A small collection of utility libraries. 4 | * [Density](https://github.com/axic/density): Alex Beregszaszi's collection of useful modifiers and methods 5 | * [Solidity Standard Library](https://github.com/ethereum/wiki/wiki/Solidity-standard-library): This is a proof-of-concept standard library that is included with Solidity itself. 6 | * [standard-contracts](https://github.com/androlo/standard-contracts/): Andreas Olofsson's collection of libraries that handle bits, bytes, encoding, decoding, and crypto. 7 | * [stringutils](https://github.com/Arachnid/solidity-stringutils): Nick Johnson's string & slice utility library -------------------------------------------------------------------------------- /Blockchain-import-and-export-instructions.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Blockchain Import/Export 3 | category: 4 | --- 5 | 6 | _**Note:** Binary format is concatenated RLP-encoded blocks_ 7 | 8 | ## C++ 9 | ### Import: 10 | ``` 11 | eth --import 12 | ``` 13 | _Formats supported: binary_ 14 | 15 | ### Export: 16 | ``` 17 | eth --export Myfile --format binary --from 45 --to latest 18 | ``` 19 | _Formats supported: hex (newlines separating), binary or JSON_ 20 | `--from` and `--to` also support blockhashes 21 | 22 | ## Go 23 | ### Import 24 | ``` 25 | geth import 26 | ``` 27 | _Formats supported: binary_ 28 | 29 | ### Genesis block: 30 | ``` 31 | geth --genesis --genesisnonce 32 | ``` 33 | _Formats supported: json_ 34 | ### Export 35 | ``` 36 | geth export 37 | ``` 38 | _Formats supported: binary_ 39 | ## Python -------------------------------------------------------------------------------- /IPv6.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: IPv6 3 | category: 4 | --- 5 | 6 | ### Goals 7 | 8 | Allow IPv6 to be used over the ethereum peer network 9 | 10 | ### Basic Design 11 | 12 | Allow IP addresses to be specified either as a 4-byte array (IPv4) or a 16-byte array (IPv6). 13 | 14 | ### Needed Changes 15 | 16 | **Peers** 17 | [`0x05`, [`ip1`: `B_4` OR `B_16`, `port1`: `P`, `id1`: `B_64`], [`ip2`: `B_4` OR `B_16`, `port2`: `P`, `id2`: `B_64`], ... ] Specifies a number of known peers. 18 | * `ip` is either a 4-byte array 'ABCD' that should be interpreted as the IPv4 address A.B.C.D or a 8-byte array 'ABCDEFGHIJKLMNOP' that should be interpreted as the IPv6 address AB:CD:EF:GH:IJ:KL:MN:OP. 19 | * `port` is a 2-byte array that should be interpreted as a 16-bit big-endian integer. 20 | * `id` is the 512-bit hash that acts as the unique identifier of the node. 21 | -------------------------------------------------------------------------------- /[Japanese]-Ethereum-TOC.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Ethereum TOC 3 | category: 4 | --- 5 | 6 | ###Ethereum 次世代スマートコントラクトとディセントラルアプリケーションレイヤー へようこそ。 7 | 8 | [Ethereum White Paper](./White-Paper) ( 英語版 ) 9 | [Ethereum 白書](./%5BJapanese%5D-White-Paper) ( 要改訳 ) 10 | 11 | 12 | 13 | [RLP](./%5BJapanese%5D-RLP), Ethereumのデータエンコードに使用される再帰的リニアプレフィックス仕様 14 | 15 | [パトリシアツリー](./%5BJapanese%5D-Patricia-Tree) 別名Trieとしても知られるマークルパトリシアツリー仕様 Ethereumにおいてブロックチェインのステートのハッシュを記憶するために使用される構造 16 | 17 | [ワイヤプロトコル](./%5BEnglish%5D-Wire-Protocol) 仕様 18 | 19 | [Serpent](./%5BEnglish%5D-Serpent-programming-language-operations), コントラクトを書くための高水準言語. チュートリアルは [こちら](./%5BEnglish%5D-Serpent-programming-language-operations). 20 | 21 | [LLL](https://github.com/ethereumproject/cpp-ethereum/wiki/LLL), Lispに似た低水準言語 "Lisp-like Language" の仕様, PoC-3以降のPoCシリーズでコントラクトを書くために使用される。 22 | 23 | [用語集](./Glossary) 24 | 25 | [暗号通貨における困難な問題 (取組中)](./Problems) -------------------------------------------------------------------------------- /eπ-Programme.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Ethereum Raspberry Pi 3 | category: 4 | --- 5 | 6 | # The Ethereum Raspberry Pi (eπ) Programme 7 | 8 | The eπ programme is aimed to get as many nodes distributed around the world as possible. Any existing Ethereum meetup group is eligible to apply. 9 | 10 | We will offer to loan the group a set of equipment to run an Ethereum node. This will include: 11 | 12 | - Raspberry Pi 2 Model B; 13 | - 64 GB fast memory card; 14 | - PSU. 15 | 16 | We expect you guys to be the ones to run the install (./Raspberry-Pi-instructions). 17 | 18 | Your node will be placed on both our public and curated node lists, and aside from allowing us to show dots all over the world, will help us better understand network dynamics and emergent effects stemming from our propagation strategies. 19 | 20 | To apply for the programme, send an application including your name, meetup group name/town and an address for shipment to epi@ethereum.org. 21 | 22 | -------------------------------------------------------------------------------- /Solidity-Tutorial.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Solidity Tutorial 3 | category: 4 | --- 5 | 6 | Solidity is a high-level language whose syntax is similar to that of JavaScript and it is designed to compile to code for the Ethereum Virtual Machine. This 7 | tutorial starts with a basic introduction to Solidity and assumes some knowledge of 8 | the Ethereum Virtual Machine and programming in general. It tries to explain all features present in the language but does not cover features like 9 | the [natural language specification](Ethereum-Natural-Specification-Format) 10 | or formal verification and is also not meant as a final specification 11 | of the language. 12 | 13 | See also [Russian version (русский перевод)](./%D0%A0%D1%83%D0%BA%D0%BE%D0%B2%D0%BE%D0%B4%D1%81%D1%82%D0%B2%D0%BE-%D0%BF%D0%BE-Solidity) 14 | >>>>>>> 787d2cbb44d0ad68fdc567516393c19127d08270 15 | 16 | *** 17 | 18 | English version moved to a new [site](https://ethereum.github.io/solidity/docs/home/). 19 | -------------------------------------------------------------------------------- /sendTransaction-return-value-proposal.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: SendTransaction Return Value Proposal 3 | category: 4 | --- 5 | 6 | After talking to Marek we came to the conclusion, that the current return value of `eth_sendTransaction` is not enough to be able to work with self send transactions. 7 | 8 | If you send a contract creation transaction, you get the contract address back, but not the transaction hash. 9 | 10 | Additional with the new proposal, we could even let non-constant contract functions return values, like gavin wanted to do it in https://github.com/ethereumproject/dapp-bin/blob/master/wallet/wallet2.sol#L237 (Currently thats impossible and that contract would be wrong) 11 | 12 | ## Proposal 13 | 14 | Instead of returning the hash or a contract address lets return a object contain everything: 15 | 16 | ```js 17 | { 18 | transactionHash: '0x234567..', 19 | contractAddress: '0x123456' // or null 20 | returnValue: '0x342567' // or null 21 | } 22 | ``` -------------------------------------------------------------------------------- /pages/ethereum-toc/[german]-ethereum-toc.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Ethereum TOC 3 | category: 4 | --- 5 | 6 | ### Willkommen bei Ethereum, der nächsten Generation von elektronischen Verträgen und der Plattform für dezentrale Anwendungen. 7 | 8 | [Ethereum whitepaper](./%5BGerman%5D-White-Paper) 9 | 10 | [RLP](./%5BEnglish%5D-RLP), die Recursive Linear Prefix - Spezifikation für Kodierung der Daten ation, used for data encoding bei Ethereum. 11 | 12 | [Patricia Tree](./%5BEnglish%5D-Patricia-Tree), die Spezifikation des Merkle Patricia Baums (aka Trie), die Struktur zum Speichern und Hashen der Blockkette in Ethereum. 13 | 14 | [Wire protocol](./%5BEnglish%5D-Wire-Protocol) Spezifikation. 15 | 16 | [CLL](./%5BEnglish%5D-CLL), die Spezifikation der "C-ähnlichen Programmiersprache" für die Gestaltung von Verträgen. 17 | 18 | [Dagger](./%5BEnglish%5D-Dagger), die "proof-of-work" Spezifikation Ethereums. 19 | 20 | [Block Protocol 2.0](./%5BEnglish%5D-Block-Protocol-2.0) 21 | 22 | [Layers](./%5BEnglish%5D-Layers) 23 | 24 | [Clearinghaus](./%5BGerman%5D-Clearinghaus) 25 | -------------------------------------------------------------------------------- /Gitter-Channels.md: -------------------------------------------------------------------------------- 1 | https://gitter.im/ethereum 2 | 3 | # Node Software ("Clients") 4 | 5 | ## Go 6 | 7 | https://gitter.im/ethereum/go-ethereum 8 | 9 | ## C++ 10 | 11 | https://gitter.im/ethereum/cpp-ethereum 12 | 13 | ## Python 14 | 15 | https://gitter.im/ethereum/pyethapp - the client 16 | 17 | https://gitter.im/ethereum/pyethereum - the core library (evm, blocks, txs, ...) 18 | 19 | https://gitter.im/ethereum/pydevp2p - p2p network 20 | 21 | ## Java 22 | 23 | https://gitter.im/ethereum/ethereumj 24 | 25 | # DApp Development 26 | 27 | https://gitter.im/ethereum/web3.js 28 | 29 | https://gitter.im/ethereum/mist 30 | 31 | https://gitter.im/ethereum/solidity 32 | 33 | https://gitter.im/ethereum/serpent 34 | 35 | # Research 36 | 37 | https://gitter.im/ethereum/research 38 | 39 | # Other 40 | 41 | https://gitter.im/ethereum/porting 42 | 43 | # Protocol 44 | 45 | https://gitter.im/ethereum/devp2p 46 | 47 | https://gitter.im/ethereum/light-client 48 | 49 | https://gitter.im/ethereum/whisper 50 | 51 | https://gitter.im/ethereum/go-ethereum/swarm 52 | 53 | 54 | -------------------------------------------------------------------------------- /Adaptive-Peer-Time.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Adaptive Peer Time 3 | category: 4 | --- 5 | 6 | ### Goals 7 | 8 | At present, a single mining peer with its clock substantially (> 25% of the expected block time) ahead of the other peers will cause problems on the network. Forks are common as peers are inconsistently forced to ignore the future blocks. 9 | 10 | A system with multiple peers should be robust to a few peers having substantially fast clocks. 11 | 12 | ### Basic Overview 13 | 14 | Each peer does a ping-sequence, each message timestamped with the hardware clock (H) directly after handshake to determine both the network traversal distance ("ping time") and an estimate of the peer's hardware clock (Hp). 15 | 16 | The clock-offset (D) of the peer then becomes it's hardware clock (H) corrected to become the median of the peer hardware clocks (median({H1, H2, ...}) = M). 17 | 18 | The clock offset (D) is dynamically evaluated as the peer set changes. 19 | 20 | ### Required Changes 21 | 22 | Protocol changes: 23 | * Ping & Pong packets include a timestamp. 24 | 25 | Rest to be implemented lazily. -------------------------------------------------------------------------------- /pages/ethereum-toc/[spanish]-ethereum-toc.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Ethereum TOC 3 | category: 4 | --- 5 | 6 | ### Bienvenidos a Ethereum, la plataforma para la siguiente generación de contratos inteligentes y aplicaciones descentralizadas. 7 | 8 | [Whitepaper de Ethereum](https://google.com) 9 | 10 | [RLP](https://google.com), Prefijo Linear Recursivo (Recursive Linear Prefix), usado para codificación de datos a través de Ethereum. 11 | 12 | [Patricia Tree](https://google.com) especificaciones del árbol Merkle Patricia (“Merkle Patria Tree”, también conocido como Trie), la estructura usada para almacenar y procesar a través de funciones Hash el estado de la cadena de bloques en Ethereum. 13 | 14 | [Protocolo de conexión](https://google.com), especificaciones. 15 | 16 | [CLL](https://google.com), Lenguage de alto nivel similar a C usado para crear contratos, especificaciones. 17 | 18 | [Dagger](https://google.com), Prueba de trabajo (Proof-of-work) de Ethereum. 19 | 20 | [Protocolo de Bloques 2.0](https://google.com) 21 | 22 | [Capas](https://google.com) 23 | 24 | [Cámara de compensación](https://google.com) 25 | -------------------------------------------------------------------------------- /Bad-Chain-Canary.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Bad Chain Canary 3 | category: 4 | --- 5 | 6 | There will be a canary contract to notify that a given chain is bad. It's very easy to use; check storage location 0 of contract at the given address (see below). If non-zero, client should not mine (at least without a non-default option being given to ignore the canary and mine on a known-bad chain). 7 | 8 | Specifically there are three modes they could be in: 9 | 10 | - `0` All fine. Carry on. 11 | - `1` Bad chain. Client should not mine on it. Client upgrade not yet available. 12 | - `2` Update required. Just as for `1`; additionally, an update to your client is available and would be prudent. 13 | 14 | Clients that implemented this protocol displayed a message to the user to make any non-zero status clear. For a status of 2, the user would be notified than an immediate upgrade was required, regardless of whether mining was enabled. 15 | 16 | #### Addresses 17 | 18 | - For Olympic: `0x6879392ee114f8a4e133f0ff3dc4bc1717fe9344` 19 | - For Frontier: Multiple people 20 | - For Homestead and later, clients don't support this contract anymore. The last clients removed this in mid-2016. -------------------------------------------------------------------------------- /Serpent_3.0.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Serpent 3.0 3 | category: 4 | --- 5 | 6 | The following is a suggested spec for Serpent 3.0. 7 | 8 | 9 | 1. Everything is strongly typed, but types are inferred, so there is no need to specify types explicitly. 10 | 11 | For example, consider the code: 12 | 13 | data bar[6] 14 | 15 | def foo(): 16 | x = 5 17 | y = [1,2,3,4,5,6] 18 | z = "123123124" 19 | w1 = y[1] 20 | w2 = z[2] 21 | self.bar = y 22 | return(x) 23 | 24 | A script would run through the code and assign types: 25 | 26 | x: int 27 | y: arr[int] 28 | z: string 29 | w1: int 30 | w2: int 31 | self.bar: arr[int] :: storage 32 | 33 | When checking the type for w1, the script would see the line `w1 = y[1]`, note that `y` is already known as an `arr[int]` so `y[1]` will be recognized as `int`. Meanwhile, `z` will be known as `string`, and so `z[1]` will be recognized as a character, ie. `int`. Note that this means that `y[1]` will be compiled as `(mload (add y 32))` whereas `z[2]` will be compiled as `(byte (mload (add z 2)) 0)`. `self.bar = y` will be processed recursively so as to copy the entire contents of `y` into `self.bar`. -------------------------------------------------------------------------------- /enode-url-format.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: ENode URL Format 3 | category: 4 | --- 5 | 6 | An Ethereum node can be described with a URL scheme "enode". 7 | 8 | The hexadecimal node ID is encoded in the username portion of the URL, separated from the host by an @ sign. The hostname can only be given as an IP address, DNS domain names are not allowed. The port 9 | in the host name section is the TCP listening port. If the TCP and UDP (discovery) ports differ, the UDP port is specified as query parameter "discport". 10 | 11 | In the following example, the node URL describes a node with IP address `10.3.58.6`, TCP listening port `30303` and UDP discovery port `30301`. 12 | 13 | ``` 14 | enode://6f8a80d14311c39f35f516fa664deaaaa13e85b2f7493f37f6144d86991ec012937307647bd3b9a82abe2974e1407241d54947bbb39763a4cac9f77166ad92a0@10.3.58.6:30303?discport=30301 15 | ``` 16 | 17 | The enode url scheme is used by the Node discovery protocol and can be used in the `bootnodes` command line option of the client or as the argument to `suggestPeer(nodeURL)` function in the JSRE. 18 | 19 | See also 20 | - https://github.com/ethereumproject/go-ethereum/wiki/Command-Line-Options 21 | - https://github.com/ethereumproject/go-ethereum/wiki/JavaScript-Console 22 | -------------------------------------------------------------------------------- /NewBlock-Message.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: NewBlock Message 3 | category: 4 | --- 5 | 6 | ### Goals 7 | 8 | At present `Blocks` messages may be sent either as a response to a `GetBlocks` message receipt or due to a new block being mined or discovered. This causes some issues for the state transition mechanisms, which are to be avoided. 9 | 10 | ### Basic Design 11 | 12 | Provide a second response type explicitly used for distributing a new block. 13 | 14 | ### Needed Changes 15 | 16 | New packet for the Ethereum sub-protocol, `NewBlock`: 17 | 18 | **Blocks** 19 | [`+0x06`, [`blockHeader`, `transactionList`, `uncleList`], `...`] Specify (a) block(s) as an answer to `GetBlocks`. The items in the list (following the message ID) are blocks in the format described in the main Ethereum specification. This may validly contain no blocks if no blocks were able to be returned for the `GetBlocks` query. 20 | 21 | **NewBlock** 22 | [`+0x07`, [`blockHeader`, `transactionList`, `uncleList`], `totalDifficulty`] Specify a single block that the peer should know about. The composite item in the list (following the message ID) is a block in the format described in the main Ethereum specification. 23 | - `totalDifficulty` is the total difficulty of the block (aka score). 24 | -------------------------------------------------------------------------------- /Dapp-Developer-Resources.md: -------------------------------------------------------------------------------- 1 | As a Ðapp developer you have three main resources which allow Ðapp development. 2 | 3 | ### Main Resources 4 | 5 | - [Web3 JavaScript API](./JavaScript-API) - This is the main JavaScript SDK to use when you want to interact with a nodes API 6 | - [JSON RPC API](./JSON-RPC) - This is the low level JSON RPC 2.0 interface to interface with a node. This API is used by the [Web3 JavaScript API](./JavaScript-API). 7 | - [Solidity Documentation](https://ethereum.github.io/solidity/docs/home/) - Solidity is the Ethereum developed Smart Contract language, which compiles to EVM (Ethereum Virtual Machine) opcodes. 8 | 9 | ### Other Resources: 10 | 11 | - [Standardized Contract APIs](./Standardized_Contract_APIs) - Standard contract API, which should be used to make some contract types accessible by other Ðapps. (Not yet finalised) 12 | - [Useful Ðapp Patterns](./Useful-Ðapp-Patterns) - Code snippets which are useful for Ðapp development. 13 | - [Dapp using Meteor](./Dapp-using-Meteor) - This short tutorial gives an intro on how to start building a Ðapp using [Meteor](https://www.meteor.com), and also why Meteor is a good fit for Ðapps. 14 | 15 | ### Useful read 16 | - [FAQ](./FAQ) - Collection of links, useful for understanding the Ethereum eco system. 17 | - [Glossary](./Glossary) - Great explanation of Blockchain related terms. -------------------------------------------------------------------------------- /web.js-0.9.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Web.js 0.9 3 | category: 4 | --- 5 | 6 | Web3.js 0.9 changes 7 | 8 | I would like to apply KISS principle to web3.js. I used the library recently much more and I realised that we are doing to many things implicitly. eg: 9 | 10 | 1, newFilter it should either get all logs or poll for new logs. It's shouldn't do both in the same time. In my story, I don't want to poll for filter changes, but I want to get all logs between block X and Y. Same as caktux here: https://github.com/ethereumproject/web3.js/issues/250 11 | 12 | examples of new solution 13 | 14 | 1st. 15 | 16 | ``` 17 | var x = web3.eth.filter(...); // sync: eth_newFilter 18 | x.watch(function (err, log) { // async poll: eth_getFilterChanges 19 | 20 | }) 21 | ``` 22 | 23 | 24 | 2nd. 25 | 26 | 27 | ``` 28 | web3.eth.filter(..., function (err, x) { // async: eth_newFilter 29 | x.watch(function (err, log) { // async poll: eth_getFilterChanges 30 | 31 | }) 32 | }) 33 | 34 | ``` 35 | 36 | 3rd. 37 | 38 | 39 | ``` 40 | var x = web3.eth.filter(...) // sync: eth_newFilter 41 | var logs = x.logs(); // sync: eth_getFilterLogs 42 | ``` 43 | 44 | 4th. 45 | ``` 46 | var x = web3.eth.filter(...) // sync: eth_newFilter 47 | var logs = x.logs(function (err, logs) { // sync: eth_getFilterLogs 48 | 49 | } 50 | ``` 51 | -------------------------------------------------------------------------------- /[Romanian]-Cuprins.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Cuprins 3 | category: 4 | --- 5 | 6 | ### Ethereum este platforma pe care se vor dezvolta aplicatii descentralizate si noua generatie de smart-contracts. 7 | 8 | [Raportul Ethereum (whitepaper)](./%5BRomanian%5D-White-Paper) 9 | 10 | [RLP](./%5BRomanian%5D-RLP), specificatii pentru prefixul liniar recursiv, folosit pentru codificarea datelor in reteaua Ethereum. 11 | 12 | [Patricia Tree](./%5BRomanian%5D-Patricia-Tree) Specificatii pentru arborele Merkle Patricia (aka Trie), structura folosita pentru stocare si hashing necesare starii blockchainului ethereum. 13 | 14 | [Wire protocol](./%5BRomanian%5D-Wire-Protocol) Specificatii. 15 | 16 | [Serpent](./%5BRomanian%5D-Serpent-programming-language-operations), un limbaj de programare high-level folosit pentru scrierea de smart-contracts. Tutorial [aici](./%5BRomanian%5D-Serpent-programming-language-operations). 17 | 18 | [LLL](https://github.com/ethereumproject/cpp-ethereum/wiki/LLL), Specificatii pentru limbajul low-level "Lisp-like Language" , folosit pentru definirea contractelor in clientul ethereum incepand cu PoC-3. 19 | 20 | [Dagger](./%5BRomanian%5D-Dagger), Detalii despre algoritmul "proof-of-work". 21 | 22 | [Block Protocol 2.0](./%5BRomanian%5D-Block-Protocol-2.0) 23 | 24 | [Layers](./%5BRomanian%5D-Layers) 25 | 26 | [Clearinghouse](./%5BRomanian%5D-Clearinghouse) -------------------------------------------------------------------------------- /Deterministic_Wallet_Spec.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Deterministic Wallet Spec 3 | category: 4 | --- 5 | 6 | Address/key generation 7 | 8 | The following is a proposed deterministic wallet specification. 9 | 10 | Let `S` be the secret. We define `key(i) = sha3(S + zpad(int_to_big_endian(i), 32))`, where `i` is an incrementing index starting at 0 11 | 12 | Assuming `S = "123dog"`, we thus have: 13 | 14 | key(0) = sha3("123dog\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00") 15 | 16 | Note that the big endian representation of 0 is the empty string. 17 | 18 | key(1) = sha3("123dog\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01") 19 | key(2) = sha3("123dog\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02") 20 | key(255) = sha3("123dog\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff") 21 | key(256) = sha3("123dog\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x00") 22 | key(4294967297) = sha3("123dog\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x01") -------------------------------------------------------------------------------- /Proposal:-BlockHashesFromNumbers.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: BlockHashesFromNumbers Proposal 3 | category: 4 | --- 5 | 6 | # Problem 7 | 8 | During initial synchronization to a large blockchain downloading block hashes can take significant time. Current protocol does not allow parallel hashes downloading. Hashes can be requested sequentially up the chain, making it impossible to start blocks downloading until all of the hashes up to the known hash or genesis are received. A malicious peer can feed an infinite hash chain. Currently it is not straightforward to protect against such an attack as there is no additional information on the number of hashes. The only strategy is to estimate a reasonable number of hashes using current date, genesis date and average block time, and then reject the peer after downloading that many hashes. 9 | 10 | # Solution 11 | 12 | There should be a way to request a list of hashes by the block number. This will allow parallel downloading, starting block downloading and validation immediately after receiving first hashes, rejecting malicious peers right away. 13 | 14 | # Specification 15 | 16 | 1. Introduce a new packet: `BlockHashesFromNumber`, into the slot `+0x08` (new). 17 | 18 | **BlockHashesFromNumber** 19 | [`+0x08`: `P`, `number`: `P`, `maxBlocks`: `P`] 20 | Requests a BlockHashes message detailing a number of the first block hash and a total of hashes to be sent. Returned hash list must be ordered by block number in ascending order. 21 | -------------------------------------------------------------------------------- /pages/ethereum-toc/[italian]-ethereum-toc.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Ethereum TOC 3 | category: 4 | --- 5 | 6 | ### Benvenuti. Ethereum: il contratto intelligente di nuova generazione e piattaforma di applicazioni decentralizzate. 7 | 8 | [Libro Bianco di Ethereum](./%5BItalian%5D-Libro-Bianco) 9 | 10 | [RLP](https://google.it), la caratteristica del prefisso lineare ricorsivo, utilizzato per la codifica dei dati attraverso Ethereum. 11 | 12 | [Patricia Tree](https://google.it) la caratteristica dell'albero Merkle Patricia (conosciuta anche come Trie), la struttura utilizzata per archiviare e processare attraverso la funzione di Hash lo stato della catena di blocchi in Ethereum. 13 | 14 | [Protocollo di connessione](https://google.it), caratteristiche. 15 | 16 | [Serpente](https://google.it), il linguaggio di alto livello usato per scrivere contratti. Vedi il tutorial qui. 17 | 18 | [LLL](https://google.it), caratteristica di Basso-Livello "Linguaggio di Basso Livello", usata per scrivere contratti nella serie PoC da Poc-3 19 | 20 | [Dagger](https://google.com), Prova di lavoro "proof-of-work" di Ethereum. 21 | 22 | [Protocollo di Blocco 2.0](https://google.it) 23 | 24 | [Protocolli](https://google.it) 25 | 26 | [Camera di Compensazione](https://google.it) 27 | 28 | [Introduzione allo sviluppo su Ethereum](./%5BItalian%5D-Introduzione-allo-sviluppo-su-Ethereum) 29 | 30 | [Impostare il proprio ambiente di sviluppo Ethereum](./%5BItalian%5D-Impostare-il-proprio-ambiente-di-sviluppo-Ethereum) -------------------------------------------------------------------------------- /Proposal:-NewBlockHashes.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: NewBlockHashes Proposal 3 | category: 4 | --- 5 | 6 | # Problem 7 | 8 | Block propagation is slow. This is partly due to the problematic strategy decision of either sending out a new block to all peers (costly in terms of bandwidth, especially when considered at the network level where most nodes will receive a block from most of their peers) or send a new block to a randomly selected subset of peers (making worst-case propagation times substantial). 9 | 10 | # Solution 11 | 12 | Much better would be a low-bandwidth full propagation of the hash. All nodes would receive a hash for each new block from most of their peers (peers who have demonstrated knowledge of the hash would not be notified). However, the block itself would need only be transferred once per node. 13 | 14 | # Specification 15 | 16 | Introduce a new packet: `NewBlockHashes`, into the slot `+0x01` (original taken by `GetTransactions`, which is not defunct). 17 | 18 | **NewBlockHashes** 19 | [`+0x01`: `P`, `hash1`: `B_32`, `hash2`: `B_32`, `...`] Specify one or more new blocks which have appeared on the network. Including hashes that the sending peer could reasonable be considered to know that the receiving node is aware of is considered Bad Form, and may reduce the reputation of the sending node. Including hashes that the sending node later refuses to honour with a proceeding `GetBlocks` message is considered Bad Form, and may reduce the reputation of the sending node. 20 | 21 | 22 | -------------------------------------------------------------------------------- /Geth-Dapp-loading-proposal.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Geth DAPP Loading Proposal 3 | category: 4 | --- 5 | 6 | To have a simple way to load and start Dapps vinay and I came up with a great idea: 7 | 8 | 1. Dapp packages can be downloaded as .zip/.rlp/.dapp 9 | - they will contain a `dapp.json` with author info and a dapp name and version. 10 | - and a `swarm.json`, with all the file paths and hashes, [see here](https://github.com/ethereumproject/go-ethereum/wiki/URL-Scheme#server-config-examples)) 11 | 12 | 2. run `$ geth install mydapp.zip`, which will verify, extract and copy the dapp locally somewhere. 13 | **Note** This could also get a name reg domain and looks up the hash an content online, fetches it and installs it. 14 | 15 | 3. run `$ geth start mydapp` will start a node, with the correct options (rpc, corsdomain etc) and start a local server which points with its root into the dapps folder and resolves path and files through the `swarm.json` 16 | 17 | 4. goto `http://localhost:5555` to see you dapp running (needs to be thought of, as dapps would share localstorage, maybe use a different and reusable port per dapp) 18 | 19 | ## Update 20 | 21 | - run `$ geth update mydapp.zip`, which will extract, and overwrites the old dapp files 22 | 23 | ## Bundle dapp 24 | 25 | - run `$ geth bundle myDappFolder/dist/`, which will create a dapp bundle from a folder, to share with others. 26 | 27 | - run `$ geth deploy myDappFolder/dist/` could save it to pastebin and register it in namereg. 28 | -------------------------------------------------------------------------------- /Whisper-Wire-Protocol.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Whisper Wire Protocol 3 | category: 4 | --- 5 | 6 | Peer-to-peer communications between nodes running Whisper clients run using the underlying [ÐΞVp2p Wire Protocol](./%C3%90%CE%9EVp2p-Wire-Protocol). 7 | 8 | This is a preliminary wire protocol for the Whisper subsystem. It will change. 9 | 10 | ### Whisper Sub-protocol 11 | 12 | **Status** 13 | [`+0x00`: `P`, `protocolVersion`: `P`] Inform a peer of the **whisper** status. This message should be send _after_ the initial handshake and _prior_ to any **whisper** related messages. 14 | * `protocolVersion` is one of: 15 | * `0x02` for PoC-7. 16 | 17 | **Messages** 18 | [`+0x01`: `P`, [`expiry1`: `P`, `ttl1`: `P`, [`topic1x1`: `B_4`, `topic1x2`: `B_4`, ...], `data1`: `B`, `nonce1`: `P`], [`expiry2`: `P`, ...], ...] Specify one or more messages. Nodes should not resend the same message to a peer in the same session, nor send a message back to a peer from which it received. This packet may be empty. The packet must be sent at least once per second, and only after receiving a **Messages** message from the peer. 19 | 20 | ### Session Management 21 | 22 | For the Whisper sub-protocol, upon an active session, a `Status` message must be sent. Following the reception of the peer's `Status` message, the Whisper session is active. The peer with the greatest Node Id should send a **Messages** message to begin the message rally. From that point, peers take it in turns to send (possibly empty) Messages packets. 23 | 24 | -------------------------------------------------------------------------------- /Ethash-DAG.md: -------------------------------------------------------------------------------- 1 | Ethash is the PoW system. It requires a great huge dataset known as the DAG (name refers to [Dagger Hashimoto](https://github.com/ethereum/wiki/blob/master/Dagger-Hashimoto.md)). This takes a good long while to generate which is a pain. As such we tend to memorise it. Clients wishing to store the DAG in a cache should conform to this spec in order to share the cache with other clients: 2 | 3 | #### Location 4 | 5 | The DAG should be stored in a 1GB dump (for the initial epoch, anyway), in a file: 6 | 7 | - Mac/Linux: `$(HOME)/.ethash/full-R-` 8 | - Windows: `$(HOME)/Appdata/Local/Ethash/full-R-` 9 | 10 | Where: 11 | 12 | - `` is a decimal integer, given as the C-constant `REVISION` in `libethash/ethash.h`; 13 | - `` is 16 lowercase hex digits specifying the first 8 bytes of the epoch's seed hash. 14 | 15 | There may be many such DAGs stored in this directory; it is up to the client and/or user to remove out of date ones. 16 | 17 | #### Format 18 | 19 | Each file should begin with an 8-byte magic number, `0xfee1deadbaddcafe`, written in little-endian format (i.e., bytes `fe ca dd ba ad de e1 fe`). 20 | 21 | The Ethash algorithm expects the DAG as a two-dimensional array of uint32s (4-byte unsigned ints), with dimension (n × 16) where n is a large number. (n starts at 16777186 and grows from there.) Following the magic number, the rows of the DAG should be written sequentially into the file, with no delimiter between rows and each unint32 encoded in little-endian format. -------------------------------------------------------------------------------- /NatSpec-Determination.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: NatSpec Determination 3 | category: 4 | --- 5 | 6 | Publishing and finding the [NatSpec] (./Ethereum-Natural-Specification-Format) documentation for a contract is an important part of the Ethereum system. There are two pieces to this puzzle: the first is for a given client to be able to determine, given a call to a contract, what a **trustworthy** NatSpec documentation hash for the contract is; the second is to find the actual NatSpec documentation body given its content hash. 7 | 8 | ### Trusted Content Determination 9 | 10 | The former, trusted content determination, will ultimately be accomplished through a sophisticated reputation system. In the meantime, we (the Ethereum foundation) will maintain our own curated repository of trusted NatSpec documentation hashes in a contract. The contract is trivial, just providing a mapping from contract code hash to NatSpec JSON file hash. It can be found [here](https://github.com/ethereumproject/dapp-bin/blob/master/NatSpecReg/contract.sol). We, alone, will retain the key updating and adding entries to this contract. 11 | 12 | This contract will have a specific address on the PoC-9 & Frontier testnet, probably referenced from the Ethereum services contract. 13 | 14 | ### Content Publishing and Distribution 15 | 16 | The latter, content publishing and distribution, will ultimately be accomplished through the "Swarm" subsystem or IPFS. Until then, we will piggy back on the existing workaround for content-based publication and distribution; the [URL Hint](./URL-Hint-Protocol) system. 17 | 18 | -------------------------------------------------------------------------------- /Ethash-DAG-Disk-Storage-Format.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Ethash DAG 3 | category: 4 | --- 5 | 6 | Ethash is the PoW system. It requires a great huge dataset known as the DAG (name refers to [Dagger Hashimoto](./Dagger-Hashimoto)). This takes a good long while to generate which is a pain. As such we tend to memoise it. Clients wishing to store the DAG in a cache should conform to this spec in order to share the cache with other clients: 7 | 8 | #### Location 9 | 10 | The DAG should be stored in a 1GB dump (for the initial epoch, anyway), in a file: 11 | 12 | - Mac/Linux: `$(HOME)/.ethash/full-R-` 13 | - Windows: `$(HOME)/Appdata/Local/Ethash/full-R-` 14 | 15 | Where: 16 | 17 | - `` is a decimal integer, given as the C-constant `REVISION` in `libethash/ethash.h`; 18 | - `` is 16 lowercase hex digits specifying the first 8 bytes of the epoch's seed hash. 19 | 20 | There may be many such DAGs stored in this directory; it is up to the client and/or user to remove out of date ones. 21 | 22 | #### Format 23 | 24 | Each file should begin with an 8-byte magic number, `0xfee1deadbaddcafe`, written in little-endian format (i.e., bytes `fe ca dd ba ad de e1 fe`). 25 | 26 | The Ethash algorithm expects the DAG as a two-dimensional array of uint32s (4-byte unsigned ints), with dimension (n × 16) where n is a large number. (n starts at 16777186 and grows from there.) Following the magic number, the rows of the DAG should be written sequentially into the file, with no delimiter between rows and each unint32 encoded in little-endian format. -------------------------------------------------------------------------------- /Security-Issue-Process.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Security Issue Process 3 | category: 4 | --- 5 | 6 | Draft of steps that should be taken when finding a security issue in Ethereum. Security issue is defined as a problem in scope of [Security-Categorization](./Security-Categorization). 7 | 8 | Partly inspired by [OWASP Risk Rating](https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology) 9 | 10 | ### Documentation 11 | 12 | * Add a entry describing the issue at (TODO: github link). 13 | * Estimate likelihood, impact and complexity of fix. 14 | * Affected software version(s). 15 | 16 | ### Estimate Likelihood 17 | 18 | * How likely is it to be uncovered and exploited by an attacker? 19 | * Ease of discovery? 20 | * Ease of exploit? 21 | * Likelihood of detection? 22 | 23 | ### Estimate Impact 24 | 25 | * Blockchain consensus. Potential of blockchain fork? 26 | * Financial damage. Loss of ether? 27 | * Privacy. E.g. revealing who sent a tx or who owns an address. 28 | * Availability. Can it impact availablity of node(s)? 29 | 30 | ### Technical description 31 | 32 | * Protocol version. 33 | * Client version(s). Single or multiple implementations? 34 | * OS / external library version(s). 35 | * Link to relevant source code. 36 | * How to fix. 37 | * How to test. 38 | 39 | ### Ownership / Responsibility 40 | 41 | * Who is assigned to fix the issue? 42 | * Who will test / review a fix? 43 | * Who takes responsibility for preparing new builds of client software? 44 | 45 | ### Disclosure 46 | 47 | * Who takes on to disclose the issue? 48 | * Communication channels (mail lists, twitter, github). 49 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | # Created by .ignore support plugin (hsz.mobi) 2 | ### JetBrains template 3 | # Covers JetBrains IDEs: IntelliJ, RubyMine, PhpStorm, AppCode, PyCharm, CLion 4 | 5 | *.iml 6 | 7 | ## Directory-based project format: 8 | .idea/ 9 | # if you remove the above rule, at least ignore the following: 10 | 11 | # User-specific stuff: 12 | # .idea/workspace.xml 13 | # .idea/tasks.xml 14 | # .idea/dictionaries 15 | 16 | # Sensitive or high-churn files: 17 | # .idea/dataSources.ids 18 | # .idea/dataSources.xml 19 | # .idea/sqlDataSources.xml 20 | # .idea/dynamic.xml 21 | # .idea/uiDesigner.xml 22 | 23 | # Gradle: 24 | # .idea/gradle.xml 25 | # .idea/libraries 26 | 27 | # Mongo Explorer plugin: 28 | # .idea/mongoSettings.xml 29 | 30 | ## File-based project format: 31 | *.ipr 32 | *.iws 33 | 34 | ## Plugin-specific files: 35 | 36 | # IntelliJ 37 | /out/ 38 | 39 | # mpeltonen/sbt-idea plugin 40 | .idea_modules/ 41 | 42 | # JIRA plugin 43 | atlassian-ide-plugin.xml 44 | 45 | # Crashlytics plugin (for Android Studio and IntelliJ) 46 | com_crashlytics_export_strings.xml 47 | crashlytics.properties 48 | crashlytics-build.properties 49 | 50 | 51 | ### OSX template 52 | .DS_Store 53 | .AppleDouble 54 | .LSOverride 55 | 56 | # Icon must end with two \r 57 | Icon 58 | 59 | # Thumbnails 60 | ._* 61 | 62 | # Files that might appear in the root of a volume 63 | .DocumentRevisions-V100 64 | .fseventsd 65 | .Spotlight-V100 66 | .TemporaryItems 67 | .Trashes 68 | .VolumeIcon.icns 69 | 70 | # Directories potentially created on remote AFP share 71 | .AppleDB 72 | .AppleDesktop 73 | Network Trash Folder 74 | Temporary Items 75 | .apdisk 76 | 77 | 78 | -------------------------------------------------------------------------------- /[Japenese]-Ethereum-TOC.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: 日本語版 3 | category: 4 | --- 5 | 6 | # ようこそ Ethereum wiki へ 7 | 8 | この項は ÐΞV によって開発された 次世代型 P2P 技術基盤 について、全情報を集約した wiki であり、イーサリアムコミュニティによって維持されています。次世代型 P2P 技術基盤 は以下の内容を含みます。 9 | * **Ethereum** : スマートコントラクト開発のために一般化を施した ブロックチェイン 10 | * **Whisper** : イーサリアムによる private low-level datagram コミュニケーション基盤 11 | 12 | どなたでも GitHub にサインインすることで [browser](https://help.github.com/articles/editing-wiki-pages-via-the-online-interface) や [locally](https://help.github.com/articles/adding-and-editing-wiki-pages-locally) に記事を追加することができます。 13 | 14 | ## 進行状況 15 | 16 | ### Frontier 17 | 18 | Ethereum Frontier は試験段階として現在運用されています。 (2015/5/1) 19 | Frontier についての詳細は [Vinay Gupta's blog post](https://blog.ethereum.org/2015/03/03/ethereum-launch-process/) をご覧ください。 20 | 21 | ## はじめに 22 | Ethereum の基本概念の理解といたしましては [ethereum whitepaper (日本語版) ](./%5BJapanese%5D-White-Paper) や [設計原理 (日本語版)](./%5BJapanese%5D-Design-Rationale--(設計原理)) もしくは論文 [ethereum yellow paper (英語版)](http://gavwood.com/Paper.pdf) をご覧ください。またエンジニアの方は [ethereum development tutorial (日本語版)](./%5BJapanese%5D--Ethereum-Development-Tutorial) をご覧ください。 23 | 24 | ## 仕様 25 | - [Glossary](./Glossary) と [FAQ](./FAQ) は必ずご覧になってください。 26 | - [C++言語](https://github.com/ethereumproject/cpp-ethereum/wiki) と [Go言語](https://github.com/ethereumproject/go-ethereum/wiki) による実装についての wiki です。 ( Python と Javascript 言語につきましてはもうしばらくお待ちください) 27 | 28 | ## ダウンロード 29 | 開発中ですが PoC-9 code は以下の git レポジトリの branch からダウンロード可能です: 30 | - https://github.com/ethereumproject/cpp-ethereum 31 | - https://github.com/ethereumproject/go-ethereum 32 | - https://github.com/ethereumproject/pyethereum 33 | 34 | 最新情報は [build server](http://build.ethdev.com/console) をご覧ください。 -------------------------------------------------------------------------------- /Tags-for-Solidity-in-code-documentation.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Tags for Solidity in Code Documentation 3 | category: 4 | --- 5 | 6 | At the moment pursuant to ./Solidity,-Docs-and-ABI 7 | the following tags are available to use after /// to provide in-code documentation. 8 | 9 | Title 10 | 11 | `/// @title Some title here.` 12 | 13 | Author 14 | 15 | `/// @author Homer Simpson` 16 | 17 | Notice 18 | 19 | ```/// @notice Send `(valueInmGAV / 1000).fixed(0,3)` GAV from the account of 20 | /// `message.caller.address()`, to an account accessible only by `to.address()`.``` 21 | 22 | Developer Documentation 23 | 24 | `/// @dev This is the developer documentation.` 25 | 26 | Docs for parameters 27 | 28 | ```/// @param to The docs for the first param. 29 | /// @param valueInmGav The docs for the second param.``` 30 | 31 | 32 | Which in json would result in something like this: 33 | 34 | ``` 35 | { 36 | "source": "...", 37 | "author": "Gav Wood", 38 | "description": "Some description of this contract.", 39 | "language": "Solidity", 40 | "languageVersion": 1, 41 | "methods": { 42 | "send": { "notice": "Send `(valueInmGAV / 1000).fixed(0,3)` GAV from the account of `message.caller.address()`, to an account accessible only by `to.address()`." }, 43 | "title": "Send some GAV.", 44 | "details": "..." 45 | "balance": { "notice": "`(balanceInmGAV / 1000).fixed(0,3)` GAV is the total funds available to `who.address()`." } 46 | }, 47 | "invariants": [ 48 | { "title": "...", "details": "Markdown description of the first invariant." } 49 | { "notice": "The sum total amount of GAV in the system is 1 million." } 50 | ], 51 | "construction": [ 52 | { "notice": "Endows `message.caller.address()` with 1m GAV." } 53 | "details": "Creates the contract with..." 54 | ] 55 | } 56 | ``` -------------------------------------------------------------------------------- /[Chinese]-Ethereum-TOC.md: -------------------------------------------------------------------------------- 1 | # 歡迎來到 Ethereum Wiki 2 | 3 | 這是社區維護的維基，包含各種由ÐΞV建造的次世代點對點科技平台，包括 **Ethereum**，_可開發智能契約的衍生區塊鏈_，和私有底層資料包通信平台**Whisper**。 4 | 5 | 登入 Github 的使用者可以[瀏覽器](https://help.github.com/articles/editing-wiki-pages-via-the-online-interface)或[本地端](https://help.github.com/articles/adding-and-editing-wiki-pages-locally)編輯與增加頁面。 6 | 7 | ## 狀態 8 | 9 | ### Homestead 10 | 11 | 第二次主要的 Ethereum 上線，也就是 Homestead，在 2016年2月29日釋出，並在 2016年3月14日成功硬分叉！Ethereum 開發持續往下個版本 Metropolis 與 Serenity (v1.1) 前進中。 Homestead 的目標為提供 [Ðapp 開發者](https://github.com/ethereum/wiki/wiki/Dapp-Developer-Resources) 與終端用戶一些類別有限的應用，而 Metropolis 旨在提供終端用戶 Mist 瀏覽器。 Serenity 將把取得共識的機制從 [Proof-of-Work](https://github.com/ethereum/wiki/wiki/Ethash) 轉換為 [Proof-of-Stake](https://blog.ethereum.org/2015/08/01/introducing-casper-friendly-ghost/) 。 12 | 13 | ## 入門 14 | 15 | 瀏覽 [http://ethereum.org](http://ethereum.org/) 以得到 Ethereum 的基本概念。如果你想獲得更深入的了解，可閱讀[白皮書](https://github.com/ethereum/wiki/wiki/White-Paper)和[設計原理](https://github.com/ethereum/wiki/wiki/Design-Rationale)。想要正式的文件，閱讀[黃皮書](http://gavwood.com/Paper.pdf)。快速開始開發智能契約，請參閱[開發教程](https://github.com/ethereum/wiki/wiki/Ethereum-Development-Tutorial)。 16 | 17 | ## 別迷路了 18 | 參閱 [生字表](https://github.com/ethereum/wiki/wiki/Glossary) 與 [FAQ](https://github.com/ethereum/wiki/wiki/FAQ)。有些實作文件可見 [C++](https://github.com/ethereum/webthree-umbrella/wiki) 與 [Go](https://github.com/ethereum/go-ethereum/wiki) ，Python 與 Javascript 敬請期待。 19 | 20 | ## 下載 21 | 最新的程式碼可從下列 git repo 中的 develop 分支 clone 下來： 22 | 23 | - https://github.com/ethereum/go-ethereum (Go) 24 | - https://github.com/ethereum/webthree-umbrella (C++) 25 | - https://github.com/ethereum/pyethapp (Python) 26 | 27 | 想知道最新 Ethereum 的建置狀態，Go 與 Python 可見 [Buildbot 實例](http://build.ethdev.com/console)， C++ 可見 [Jenkins 實例](http://52.28.164.97/)。 -------------------------------------------------------------------------------- /Javascript-Development-Deficiencies.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Javascript Development Deficiencies 3 | category: 4 | --- 5 | 6 | The medium-term vision for the Ethereum javascript development tools is simple: to make developing a dapp as easy as developing a web page. However, we are not quite there yet; this page provides a partial list of the problems that dapp developers have to deal with that web developers do not. 7 | 8 | ### Transaction Asynchrony and Uncertainty 9 | 10 | When sending an ajax request to a server, that request (i) processes immediately, (ii) is either answered by the server or fails immediately, and (iii) has an effect that we know is final. When sending a transaction, we lose many of these benefits: 11 | 12 | 1. When you send a transaction, it takes ~0-30 seconds for the transaction to get included in a block. 13 | 2. When a transaction does get included in a block, it could get un-included later due to blockchain reorgs, and could then get double-spent. 14 | 3. The transaction gas a gas limit and a gas price, and either of these could lead to failures: in the first case an OOG exception, and in the second case a failure to get the transaction to get included for even longer (possibly forever). It is not possible to tell for sure when this has happened. 15 | 16 | We also lack good ways of dealing with the output of non-constant transactions; for example, a common workflow is creating a transaction that registers a new record in a contract and then getting back the ID of that record or a success or failure confirmation, and there currently is no convenient coding pattern for getting that output back. 17 | 18 | ### Failure and retrying 19 | 20 | If a transaction fails for some reason (eg. gas price too low, out of gas), it may be prudent to automatically retry with a higher gas price or gas limit. -------------------------------------------------------------------------------- /Poll-for-token-proposal-EIP-20.md: -------------------------------------------------------------------------------- 1 | Poll for https://github.com/ethereum/EIPs/issues/20 2 | 3 | github username | IN | OUT | NextEIP*? | Comments 4 | ----------------|----------------|---------------|-----------------------------------|--------- 5 | example | Set1, identifier | decimals, approve, unapprove, allowance | YES | 6 | christianlundkvist| Set1 | decimals | YES | 7 | nmushegian | Set1 | decimals | YES | 8 | joeykrug | Set1, identifier | ? | ? | 9 | koeppelmann | Set1, identifier | ? | ? | 10 | Georgi87 | Set1, identifier | decimals | Yes | 11 | niran | Set1 | decimals | YES?| 12 | ethers | Set1, identifier | decimals | YES | 13 | simondlr | Set1 | decimals | YES | 14 | frozeman | Set1, decimals | | NO | 15 | alexvandesande | Set1, decimals | | | 16 | caktux | Set1, decimals | | | 17 | firecar96 | Set1 | decimals, identifier | YES | 18 | 19 | 20 | * Set1 = balanceOf, transfer, transferFrom, totalSupply, approve, unapprove, allowance 21 | * "identifier" = https://github.com/ethereum/EIPs/issues/20#issuecomment-158436720 and the discussion 22 | * NextEIP means should the OUT items be in separate EIP/s or be in EIP20 itself but marked Optional. YES means separate EIP/s, NO means keep in EIP20 and mark it Optional. 23 | -------------------------------------------------------------------------------- /Brain-Wallet.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Brain Wallet 3 | category: 4 | --- 5 | 6 | Ethereum brain wallets are formed through applying the SHA3 to a seed to get a result `R`, then using `R` as an accumulator for 16384 repeat SHA3 operations. This process is continued until the result, when used as a private key, forms a valid Direct ICAP (34 digit) address, defined as the first byte of the address being 0. 7 | 8 | ``` 9 | FUNCTION toBrain(STRING seed) RETURNS SECRET 10 | A = SHA3(seed) 11 | REPEAT 16384 TIMES 12 | A = SHA3(A) 13 | END REPEAT 14 | WHILE SECRET_TO_ADDRESS(A)[0] != 0 DO 15 | A = SHA3(A) 16 | END WHILE 17 | RETURN A 18 | END FUNCTION 19 | ``` 20 | 21 | See [C++ implementation](https://github.com/ethereumproject/cpp-ethereum/blob/develop/libethcore/KeyManager.cpp#L215-L225) for an example. 22 | 23 | 24 | ### **Comments (Gustav):** 25 | 26 | Recent advancement in brain wallet cracking [1] show how vulnerable brain wallets are to weak passwords. Applying a KDF hardens brain wallets by reducing number of passwords an attacker can generate per second. 27 | 28 | Even though the seed in AZ is generated for people and can thus be designed to have enough entropy, it is desirable to configure a KDF to be as strong as possible without impacting usability. 29 | 30 | Benchmarking SHA3 in Go [2] on a i5-4278U CPU @ 2.60GHz gives 16384 hashes in 30ms. A C implementation on a high-end CPU would be significantly faster. 31 | 32 | I would recommend we configure a KDF that is much harder (even up to 1-2s CPU time) and also has a memory cost. Scrypt comes to mind, which we already specify in for the key storage [3]. 33 | 34 | This would make our brainwallets much harder to crack, and perhaps even allowing the seed to be shorter, improving usability. 35 | 36 | 1. https://rya.nc/cracking_cryptocurrency_brainwallets.pdf 37 | 2. https://github.com/ethereumproject/go-ethereum/blob/master/crypto/crypto_test.go#L65 38 | 3. ./Web3-Secret-Storage-Definition -------------------------------------------------------------------------------- /Parallel-Block-Downloads.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Parallel Block Downloads 3 | category: 4 | --- 5 | 6 | New network protocol & strategy. 7 | 8 | ### Goals 9 | - Achieve parallel downloads of chain 10 | - Introduce framework that can form basis of Swarm 11 | - Minimise unnecessary block transfers 12 | 13 | ### Basic Overview 14 | 15 | - Two peers connect & say Hello. Hello includes the TD & hash of their best block. 16 | - The client with the worst TD asks peer for full chain of just block hashes. 17 | - Chain of hashes is stored in space shared by all peer connections, and used as a "work pool". 18 | - While there are hashes in the chain of hashes that we don't have in our chain: 19 | - Ask for N blocks from our peer using the hashes. Mark them as on their way so we don't get them from another peer. 20 | 21 | ### Required Changes 22 | 23 | Network protocol: 33 24 | 25 | Additional parameters to Hello: 26 | - `TD`: Total Difficulty of the best chain. Integer. 27 | - `BestHash`: The hash of the best (i.e. highest TD) known block. 28 | - `GenesisHash`: The hash of the Genesis block. 29 | 30 | Additional Message types: 31 | - `0x17`: `GetBlockHashes` [ `hash` : `B_32`, `maxBlocks`: `P` ]: Requests a `BlockHashes` message of at most `maxBlocks` entries, of block hashes from the blockchain, starting at the parent of block `hash`. Does not _require_ the peer to give `maxBlocks` hashes - they could give somewhat fewer. 32 | - `0x18`:`BlockHashes` [ `hash_0`: `B_32`, `hash_1`: `B_32`, .... ]: Gives a series of hashes of blocks (each the child of the next). This implies that the blocks are ordered from youngest to oldest. 33 | - `0x19`:`GetBlocks` [ `hash_0`: `B_32`, `hash_1`: `B_32`, .... ]: Requests a `Blocks` message detailing a number of blocks to be sent, each referred to by a hash. Note: Don't expect that the peer necessarily give you all these blocks in a single message - you might have to re-request them. 34 | 35 | Remove Message types: 36 | - `GetChain` 37 | - `NotInChain` -------------------------------------------------------------------------------- /Mix-improvement-proposal.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Mix Improvement Proposal 3 | category: 4 | --- 5 | 6 | how it currently looks, its working well for very simple scripts, but its hard to impossible to use for any advanced javascript application, using require.js, common.js, bower, npm, angualr.js, ember, canjs, meteor or any more advanced js framework. As the current deploy method forces you to do things in a simplistic way (linking ethereum.js, contracts files and add the contract variable) 7 | 8 | This also makes it hard to test your application as the deploy process is the one, which uploads the contracts as well and nobody want to deploy its app and contracts without being able to thoroughly test them on the main/test net beforehand. 9 | 10 | Additionally not all dapps use one or more contracts, but might want to deploy contracts on the fly (like the wallet dapp) and need a simple way to get the compiled contract code. 11 | 12 | So here a re my suggestions: 13 | 14 | - Deploy should only deploy the app files (with the possibility to choose a to-deploy-folder), and can include the automated name reg stuff as well 15 | 16 | - contracts should be deployed by right clicking them -> deploy contract, which then asks where to deploy (testnet, mainnet) and gives back the ABI and address (maybe in a `myContract-deployed.js`) 17 | 18 | - contracts should also be compiled with right click -> compile contract, giving the compiled HEX string and ABI in an `myContract-compiled.js` (or just use one `myContract-mix.js`) 19 | 20 | - the files in the sidebar should show the folder structure and not sort by type, as any advanced js application needs more than just an index.html and js file. (folders are good ;) 21 | 22 | - the deployable file should be zip, not rlp so people can unpack it easily and discover the content which will be deployed. This also allows to understand it and write separate bundle scripts for them. **(But, might anyway become obsolete with swarm)** 23 | 24 | I think this improvements, will allow for greater flexibility without compromising the use of mix. -------------------------------------------------------------------------------- /Ethash-C-API.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Ethash C API 3 | category: 4 | --- 5 | 6 | This is just a documentation of the request of the C API described in [this PR](https://github.com/ethereumproject/ethash/pull/11). 7 | 8 | ```c 9 | typedef int(*Callback)(unsigned); 10 | typedef /*...*/ ethash_light_t; 11 | typedef /*...*/ ethash_full_t; 12 | typedef struct ethash_h256 { uint8_t b[32]; } ethash_h256_t; 13 | typedef struct ethash_result { ethash_h256_t value; ethash_h256_t hixhash; } ethash_result_t; 14 | 15 | ethash_light_t ethash_light_new(unsigned number); 16 | ethash_result_t ethash_light_compute(ethash_light_t light, ethash_h256_t header_hash, uint64_t nonce); 17 | void ethash_light_delete(ethash_light_t light); 18 | 19 | ethash_full_t ethash_full_new(ethash_light_t light, CallBack c); 20 | uint64_t ethash_full_dag_size(ethash_full_t full); 21 | void const* ethash_full_dag(ethash_full_t full); 22 | ethash_result_t ethash_full_compute(ethash_full_t full, ethash_h256_t header_hash, uint64_t nonce); 23 | void ethash_full_delete(ethash_full_t full); 24 | ``` 25 | 26 | non-zero return from Callback means "cancel DAG creation" - this should cause an immediate return of `ethash_full_new` with 0. 27 | 28 | an object of type `ethash_full_t` may be tested for validity with != 0 29 | 30 | ### Example usage: 31 | ```c 32 | int callback(unsigned _progress) 33 | { 34 | printf("\rGenerating DAG. %d%% done...", _progress); 35 | return 0; 36 | } 37 | void main() 38 | { 39 | ethash_light_t light; 40 | ethash_h256_t seed; 41 | // TODO: populate p, seed, light 42 | ethash_full_t dag = ethash_full_new(light, seed, &callback); 43 | if (!dag) 44 | { 45 | printf("Failed generating DAG :-(\n"); 46 | exit(-1); 47 | } 48 | printf("DAG Generated OK!\n"); 49 | 50 | ethash_h256_t headerHash; 51 | // TODO: populate headerHash 52 | uint64_t nonce = time(0); 53 | ethash_result ret; 54 | for (; !isWinner(ret); nonce++) 55 | ret = ethash_full_compute(dag, headerHash, nonce); 56 | printf("Got winner! nonce is %d\n", nonce); 57 | ethash_full_delete(dag); 58 | } 59 | ``` -------------------------------------------------------------------------------- /newBlockFilter-Improvement-Proposal.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: NewBlockFilter Improvement Proposal 3 | category: 4 | --- 5 | 6 | Currently a filter created with `eth_newBlockFilter` and call `eth_getFilterLogs`, or `get_filterChanges` should return `[null]` or `[null, null,...]` If multiple blocks came in since the last poll. 7 | 8 | Thats fine as you can check for the current block e.g. using: 9 | 10 | ```js 11 | web3.eth.filter('latest').watch(function(err, res){ 12 | // i can get the current block here 13 | web3.eth.getBlock('latest'); 14 | }); 15 | ``` 16 | 17 | The problem is that when a lot of blocks came in since the last time you polled with a return of `[null, null, null, ...]`, your callback will fire multiple times accordingly, but using `eth.getBlock` inside will always give me the latest block, which is actually wrong. 18 | 19 | 20 | 21 | # New Proposal 22 | 23 | After discussing with Gavin we came up with the following improvement: 24 | 25 | ```js 26 | // eth_newBlockFilter will receive no parameter 27 | {"jsonrpc":"2.0","method":"eth_newBlockFilter","params":[],"id":529} 28 | 29 | // poll 30 | {"jsonrpc":"2.0","method":"eth_getFilterChanges","params":["0xb"],"id":530} // we assume the filter ID is "0xb" 31 | 32 | // should return one or more blocks, 33 | // depending on how much arrived since the last poll 34 | { 35 | "id": 530, 36 | "jsonrpc": "2.0", 37 | "result": ['0x234234234..','0x342342342..'] // block hashes of the incoming blocks 38 | } 39 | ``` 40 | 41 | ```js 42 | // eth_newPendingTransactionFilter will receive no parameter 43 | {"jsonrpc":"2.0","method":"eth_newPendingTransactionFilter","params":[],"id":529} 44 | 45 | // poll 46 | {"jsonrpc":"2.0","method":"eth_getFilterChanges","params":["0xb"],"id":530} // we assume the filter ID is "0xb" 47 | 48 | // should return one or more pending transactions, 49 | // which were added to the pending state since the last poll 50 | { 51 | "id": 530, 52 | "jsonrpc": "2.0", 53 | "result": ['0x234234234..','0x342342342..'] // tx hashes of new pending transactions 54 | } 55 | ``` 56 | 57 | **Note** This requires that `eth_getTransactionByHash` also return pending transactions! -------------------------------------------------------------------------------- /First-steps-with-ethereum-JSON-RPC.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: First Steps wih Ethereum JSON RPC 3 | category: 4 | --- 5 | 6 | # First steps with ethereum JSON-RPC 7 | 8 | 9 | #### 1. clone cpp-ethereum or install it 10 | 11 | ##### manual installation 12 | 13 | ```bash 14 | git clone https://github.com/ethereumproject/cpp-ethereum 15 | cd cpp-ethereum 16 | mkdir build 17 | cd build 18 | cmake .. 19 | make -j 4 20 | ``` 21 | 22 | ##### automatic installation 23 | 24 | build instructions are [here](https://github.com/ethereumproject/cpp-ethereum/wiki/Installing-clients) 25 | 26 | 27 | #### 2. run eth (headless client) 28 | 29 | ```bash 30 | eth -j 31 | ``` 32 | 33 | `-j` option will start ethereum node with jsonrpc http server at port 8080 34 | 35 | etheruem should be ready to use now 36 | 37 | type in console to check if everything is working fine 38 | 39 | ``` 40 | curl -X POST --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":83}' http://localhost:8080 41 | ``` 42 | 43 | #### 3. mine and connect to the network 44 | 45 | try running 46 | 47 | ```bash 48 | eth -j -m true -f -b 49 | ``` 50 | 51 | where: 52 | - `-m true` - to do anything in ethereum, you need some ethere, let's mine 53 | - `-f` - mine with force, even if there are no transactions to mine 54 | - `-b` - connect to ethereum network 55 | 56 | *with latest version of cpp-ethereum it may take some time to connect to network. If you see any delays with jsonrpc responses, or crashes contant us. We are probably aware of them, but it's good to know about any possible vulnerability* 57 | 58 | #### 4. json-rpc methods, that you might be intrested in: 59 | 60 | - [eth_sendTransaction](./JSON-RPC#eth_sendtransaction) - used to send transaction / create contract 61 | - [eth_newBlockFilter](./JSON-RPC#eth_newblockfilter) - be notified any time there is new block on the chain 62 | - [eth_newFilter](./JSON-RPC#eth_newfilter) - create new custom filter and listen to blockchain events matching this filter 63 | - [eth_compileSolidity](./JSON-RPC#eth_compilesolidity) - used to compile solidity code 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | -------------------------------------------------------------------------------- /EVM-JIT-Binary-Interface.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: EVM JIT Binary Interface 3 | category: 4 | --- 5 | 6 | # JIT C Interface 7 | 8 | ``` C 9 | #include 10 | 11 | // JIT object opaque type 12 | typedef struct evm_jit evm_jit; 13 | 14 | // Contract execution return code 15 | typedef int evm_jit_return_code; 16 | 17 | // Host-endian 256-bit integer type 18 | typedef struct i256 i256; 19 | 20 | // Big-endian right aligned 256-bit hash 21 | typedef struct h256 h256; 22 | 23 | // Runtime data struct - must be provided by external language (Go, C++, Python) 24 | typedef struct evm_jit_rt evm_jit_rt; 25 | 26 | // Runtime callback functions - implementations must be provided by external language (Go, C++, Python) 27 | void evm_jit_rt_sload(evm_jit_rt* _rt, i256* _index, i256* _ret); 28 | void evm_jit_rt_sstore(evm_jit_rt* _rt, i256* _index, i256* _value); 29 | void evm_jit_rt_balance(evm_jit_rt* _rt, h256* _address, i256* _ret); 30 | // And so on... 31 | 32 | evm_jit* evm_jit_create(evm_jit_rt* _runtime_data); 33 | 34 | evm_jit_return_code evm_jit_execute(evm_jit* _jit); 35 | 36 | void evm_jit_get_return_data(evm_jit* _jit, char* _return_data_offset, size_t* _return_data_size); 37 | 38 | void evm_jit_destroy(evm_jit* _jit); 39 | ``` 40 | 41 | # Return Code 42 | 43 | Informs user about contract exit status: 44 | 45 | Code| Exit Status 46 | ----|----- 47 | 0 | Stop 48 | 1 | Return 49 | 2 | Suicide 50 | 101 | Bad Jump Destination 51 | 102 | Out Of Gas 52 | 103 | Stack Underflow 53 | 104 | Bad Instruction 54 | 55 | 56 | 57 | # JIT Runtime Data 58 | 59 | A set of data possibly needed by running contract, sometimes by the compiler itself. 60 | Can be called ExtVM data in C++, VMEnv data in Go. 61 | 62 | Name | Type | Access | Description 63 | ----- |------|--------|------------ 64 | Gas | i256 | inout | Gas counter. 65 | Address | h256 | in | Account address. 66 | Caller | h256 | in | 67 | Origin | h256 | in | 68 | CallValue | i256 | in | 69 | CallDataSize | i256 | in | 70 | GasPrice | i256 | in | 71 | PrevHash | i256 | in | 72 | CoinBase | h256 | in | 73 | TimeStamp | i256 | in | 74 | Number | i256 | in | 75 | Difficulty | i256 | in | 76 | GasLimit | i256 | in | 77 | CodeSize | i256 | const | 78 | CallData | byte*| in | 79 | Code | byte*| const | 80 | -------------------------------------------------------------------------------- /pages/white-paper/[persian]-white-paper.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: White Paper 3 | category: 4 | --- 5 | 6 | # پلتفرم نسل بعدی قراردادهای هوشمند و نرم افزارهای غیر متمرکز 7 | در چند ماه گذشته خیل عظیمی از علاقه مندی جهت استفاده از بلاک چین های نظیر بیت کوین وجود داشته است. - مکانیزمی که امکان توافقی جهانی را بر روی پایگاه داده ای از اطلاعات تملک افراد فراهم می آورد. - به عنوان چیزی بیش از صرفا یک پول! 8 | این کاربردها عموما شامل دسترسی دیجیتالی مبتنی بر بلاک چین به ارزهای طراحی شده در این سیستم و ابزارهای مالی می شوند. (سکه های رنگی) «دارایی های هوشمند» ابزارهایی هستند مانند یک خودرو که یک سکه رنگی را بر روی یک بلاک چین دنبال میکنند تا مالک قانونی خود را معین کنند که به خوبی سایر نرم افزارهای مدرن نظیر صرافی غیر متمرکز، مشتقات مالی، بازی های بخت آزمایی نظیر به نظیر و هویت مبتنی بر بلاک چین و سیستم های اعتباری کار میکنند. 9 | شاید بلند پروازانه ترین مورد در بین تمام برنامه های ذکر شده، مفهوم عوامل خودمختار یا سازمان خودمختار و غیر متمرکز (DAOs ) باشد- نهادهایی مستقل که در بلاک چین عمل میکنند و هیچ گونه کنترل مرکزی ندارند، اجتناب از هرگونه وابستگی به قراردادهای قانونی و آیین نامه های سازمانی با هدف داشتن منابع و بودجه مستقل توسط یک قرارداد هوشمند خودمختار که در بلاک چینی رمزنگاری شده اداره می شود. 10 | با این حال، امروزه پیاده سازی بسیاری از این برنامه های کاربردی دشوار است، چرا که سیستم های برنامه نویسی بیت کوین و حتی نسل بعدی پروتکل های ارزهای رمزنگاری شده مانند بیت کوین مبتنی بر پروتکل سکه های رنگی و به اصطلاح "metacoins"، به مراتب محدودتر از آن هستند که اجازه انجام محاسبات دلخواه و پیچیده مورد نیاز DAOها را فراهم آورند. 11 | کاری که این پروژه در صدد انجام آن است گرفتن نوآوری پروتکلهای اینچنین و ایجاد فضای کار رمزنگاری شده ای کاملا تکامل یافته و ….. (ولی با قواعد آزاد) است که به شرکت کنندگان امکان نگارش قراردادهای دلخواه پیچیده را می دهد، عوامل و روابطی که کاملا توسط بلاک چین نمایندگی خواهند شد. 12 | کاربران بسیار بیشتر از آنکه محدود به یک سری انواع تراکنش ها باشند قادر خواهند بود از اتریوم به عنوان مجموعه ای از لگوهای ابزارهای مالی رمزنگاری شده استفاده کنند. گفته میشود که فرد قادر خواهد بود از هر قابلیتی که افراد در زبان های برنامه نویسی داخل کامپیوتر در اختیار دارند استفاده کند. 13 | ارزهای سفارشی، مشتقات مالی، سیستم های تشخیص هویت و سازمانهای غیر متمرکز همگی به راحتی قابل اجرا خواهند بود، اما از همه مهمتر اینکه بر خلاف سیستم های قبلی امکان ایجاد آن دسته از تراکنشهایی که توسعه دهندگان ایتریوم حتی تصور آن را نمی کرده اند نیز فراهم است. امیدواریم ایتریوم به خوبی به عنوان تکمله ای بر اکوسیستم پول های رمزنگاری شده مورد توجه قرار گیرد چنانکه ظهور وب ۲ برای اینترنت غیر پویای سال ۱۹۹۹ بود. 14 | 15 | -------------------------------------------------------------------------------- /شركة-المنارة.md: -------------------------------------------------------------------------------- 1 | شركة المنارة تعد افضل شركة مكافحة حشرات بالرياض ان خدمات مكافحة الحشرات تحتاج الي شركة متميزة و رائعة فنحن نعمل علي القضاء علي الحشرات بشكل رائع كما اننا نقدم لكم ايضا افضل الخدمات الرائعة و هي تخزين الاثاث تن خدمات تخزين الاثاث تحتاج الي مجهود كبير للغاية عزيزي العميل عليك ان تعرف ان شركة المنارة افضل شركة لتخزين الاثاث الخاص بك نمتلك افضل مستودعات مجهزة بالمملكة العربية السعودية شركة تخزين عفش بالرياضنحن شركة المنارة نقوم بتخزين الاثاث بافضل الطرق التي تجعل الاثاث امن فنحن نقوم بتخزين الاثاث في مستودعات تخزين اثاث بالرياض نحن شركة المنارة افضل عزيزي العميل عليك ان تعرف ان المنارة هي من افضل شركات الخدمات المنزلية الموجودة في الرياض كما اننا نقدم لكم خدمة جديدة و رائعة و هس خدمة تنظيف الكنب فنقدمها لكم خلال الرابط التاليشركة تنظيف كنب بالرياض تنظيف الكنب من الخدمات المهمة للغاية فان كل شركة تعمل علي تنظيف الكنب بدقة فنحن افضل شركة تنظيف كنب بالرياض نعد افضل تسلك المجاري خدمة صعبة فتحتاج الي شركة تمتلك مجهود كبير و تكون بارعة و تكون قوية اذا كنت تبحث عن شركة فنحن افضل شركة لتلك الخدمات بالكامل شركة تسليك مجاري بالرياض كما اننا نهتم بخدمة تنظيف الخزانات فنحن افضل الخزانات من الاشياء التي تحتاج الي عملة التنظيف باستمرار فنان عمليات التنظيف تعد من الاشياء التي وصي بها رسول الله صلي الله عليه و سلم فنحن نقوم بتنظيف الخزانات بدقة و نقوم بتعقيمها جيدا شركة تنظيف خزانات بالرياضو نحن نريد ان نكون الافضل علي الاطلاق المكافحة مهمة للغاية فنحن نقوم بمكافحة الحشرات الموجودة في المنازل او البيوت او في الفلل او في الحدائق اتصل الان لكي تحصل علي الراحة التامة 2 | كما اننا افضل مكافحة حشرات بالرياض نعتمد علي العمالة المدربة علي مستوي 3 | -------------------------------------------------------------------------------- /Natspec-Example.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: NatSpec Example 3 | category: 4 | --- 5 | 6 | # Introduction 7 | 8 | This is intended as an example of proof of concept of the natspec evaluation in Alethzero, the CPP client and as a showcase of the functionality of Natspec comments. 9 | 10 | # Steps 11 | 12 | ## Create the natspec documentation 13 | 14 | Open up alethzero client and type in the following contract that we will use as an example 15 | 16 | ``` 17 | contract test { 18 | /// @notice Will multiply `a` by 7. 19 | function multiply(uint a) returns(uint d) { 20 | return a * 7; 21 | } 22 | } 23 | ``` 24 | 25 | ![Creating natspec in AZ](images/natspec1.png) 26 | 27 | Then press the `Execute` button in order to generate the contract creation transaction. We can do that from the JSON Api too but we are using AlethZero in order to create the natspec documentation from the contract. Pressing the execute button will create a local database entry (LevelDB) of a mapping of the contract's hash to the natspec documentation. 28 | 29 | This is just a temporary solution to showcase the functionality of natspec. The idea is for people to be able to retrieve natspec documentations of contracts from a trusted authority which most users can trust. 30 | 31 | ## Open up the example contract 32 | 33 | ![Opening up example contract](images/natspec2.png) 34 | We will be using the JSON Api to try and perform the only transaction that our example contract has defined in its interface. Open up Alethzero's internal browser and type in the following path to get to our example `/path/to/cpp-ethereum/libjsqrc/ethereumjs/example/natspec_contract.html`. 35 | 36 | You should see a page similar to below. Press the button to start the example. 37 | ![Starting natspec example](images/natspec3.png) 38 | ## Performing the transaction 39 | 40 | This is the interface our _application_ has for the contract. Using the textbox we can provide the input to the transaction and then execute it. 41 | 42 | ## Authentication 43 | 44 | At this final stage is where natspec actually comes into place. Each and every transaction has an authentication stage. The natspec documentation is what is provided to the user in order to notify him of the transaction and query whether or not to go ahead with it. 45 | ![Authenticating natspec](images/natspec4.png) 46 | 47 | As you can see from the picture below even if a contract's transaction does not have any specific documentation we will still get a generic popup message asking us whether or not we want to authenticate the transaction. 48 | ![Authenticating unknown transaction](images/natspec5.png) -------------------------------------------------------------------------------- /This Week In Ethereum 47.2014.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: This Week in Ethereum 47 3 | category: 4 | --- 5 | 6 | ###Current Status 7 | 8 | We are in the last days of preparing the POC-7 release. It is scheduled to ship on 21th of November. Latest stable release is Po6, testnet is reachable here, chain explorer here. Release of PoC8 is expected to be on christmas. Alpha releases are expected for mid January 2015. Release of the genesis is scheduled for March 2015. 9 | 10 | ### Protocol 11 | * Version update to eth:34 12 | * Blogs/Blooms/Recipes 13 | There are often going to be situations where contracts need to record events that will be indexible/accessible/provable by light clients and these events are often fire-and-forget. 14 | So filling a storage index for them is very wasteful. 15 | We solve this by adding a an opcode LOG, whose purpose it is to create an event that gets put into the receipt trie of the block but is not stored in the state. The transactions trie is split up into two tries. 16 | (1) transactions only 17 | (2) medstate, gas, and logs (the recipes) 18 | 19 | * Exception severity uniformity 20 | See: https://ethereum.etherpad.mozilla.org/14 21 | 22 | ## Clients 23 | ### AlethZero 24 | * Commandline option -v now also reports protocol version 25 | * Cleaned up make files 26 | * ... 27 | 28 | ### Mist 29 | * Added LOG opcode 30 | * Refactored XYZ 31 | 32 | ###pyethereum 33 | * Added LOG opcode 34 | * Refactored logging to give log structured (machine readable) data 35 | 36 | ##Projects 37 | 38 | * Continuous Integration: The bootstrapping node was extended to also host a "eth" protocol node. 39 | * Serpent 2.0: was updated to feature function definitions and proper data structures 40 | * Solidity: First compiled contracts are working and on the PoC7 testnet 41 | * Security Audit 42 | Results of a preliminary GO code audit were provided by Sergio. Jutta is working on contracting external auditors. 43 | * Stress Testing: Sven is working on the infrastructure to run and analyze various scenarios in a synthetic test network. 44 | * Berlin Office: Almost done, move in is scheduled for Monday. 45 | 46 | ##People: 47 | * Yann joined DEV Berlin and will work on the IDE 48 | * Jutta joined and will work on security audits 49 | 50 | ##In the Media 51 | Worldwide coverage of Vitalik winning the 2014 Software Innovation Award at the World Technology Awards. 52 | 53 | ##Upcoming Events 54 | 55 | ### Meetups 56 | * Berlin 18.11.14 57 | * NYC, Paris, Tokio 58 | 59 | ###DEVCon-000 60 | The first Ethereum developer conference is happening during the next week in our new office in Berlin. 61 | -------------------------------------------------------------------------------- /[中文]-网络状态.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Network Status 3 | category: 4 | --- 5 | 6 | Special thanks to Kyle Chen for translation. 7 | 8 | # 网络状态监控 9 | 10 | 以太坊（中心化的）网络状态监控器 （有时被称为“eth-netstats”），是一个基于网页的应用程序，通过一组节点去监控测试链或者主链的健康状态。 11 | 12 | ### 登记你的节点 13 | 14 | 要登记你的节点，你必须安装客户端的信息中继器，这是一个节点模块。这里给出的指示可以在Ubuntu Linux上使用（Mac OS X使用同样的指示，不过sudo指令可能不是必须的）。其他平台会有所变化（请确保nodejs-legacy也安装了，不然一些模块可能会失效。） 15 | 16 | 用Git clone指令复制程序库，然后用install指令安装PM2 17 | 18 | git clone https://github.com/cubedro/eth-net-intelligence-api 19 | cd eth-net-intelligence-api 20 | npm install 21 | sudo npm install -g pm2 22 | 23 | 然后编辑里面的app.json文件去配置你的节点：\ 24 | 25 | * 修改LISTENING_PORT选项右边的数值，将其改成以太坊的监听端口（默认：30303） 26 | * 修改 INSTANCE_NAME选项右边的数值，改成你想给节点起的名字； 27 | * 如果你想修改联系信息，将CONTACT_DETAILS选项右边的值改动 28 | * 修改RPC_PORT选项右边的数值，改成你的节点的RPC端口（在cpp和go的版本中都是默认8545的端口）; 29 | * 修改WS_SECRET选项右边的值，改成密令secret（你必须从官方的Skype联系渠道）获得 30 | 31 | 最后用以下的指令去运行进程： 32 | 33 | pm2 start app.json 34 | 35 | 一些指令是可用的： 36 | 37 | * pm2 list 以显示进程状态; 38 | * pm2 logs 以显示记录; 39 | * pm2 gracefulReload node-app 以用于软重启; 40 | * pm2 stop node-app 以停止应用程序; 41 | * pm2 kill 以停止后台进程. 42 | 43 | ### 升级 44 | 45 | 如果想升级的话，需要根据以下步骤进行： 46 | 47 | * git pull 以获取最新的版本 48 | * sudo npm update 以更新程序依赖库 49 | * pm2 gracefulReload node-app以重新载入客户端 50 | 51 | ## 在一个干净的Ubuntu系统里自动安装 52 | 53 | 获取和运行build shell。这会安装你需要的所有东西：在develop开发分支（你可以选eth或者geth）里面的ethereum – CLI, node.js, npm & pm2. 54 | 55 | bash <(curl https://raw.githubusercontent.com/cubedro/eth-net-intelligence-api/master/bin/build.sh) 56 | 57 | ### 配置 58 | 59 | 通过修改processes.json配置应用程序。注意你必须修改 ./bin/processes.json，这是processes.json的备份。（以让你可以设置环境变量，而不需要在更新的时候重写它） 60 | 61 | "env": 62 | { 63 | "NODE_ENV" : "production", //告诉客户端我们在生产环境 64 | "RPC_HOST" : "localhost", // eth JSON-RPC Host，默认是8545 65 | "RPC_PORT" : "8545", // eth JSON-RPC 端口 66 | "LISTENING_PORT" : "30303", // eth监听端口（只用于显示） 67 | "INSTANCE_NAME" : "", // 你想给节点起的名字 68 | "CONTACT_DETAILS" : "", //如果你想的话可以在这里加入你的联系信息，如电子邮件或skype 69 | "WS_SERVER" : "wss://stats.ethdev.com", //eth-netstats WebSockets api服务器的路径 70 | "WS_SECRET" : "", // 用于登陆的WebSockets api 服务器密令secret } 71 | 72 | ## 运行 73 | 74 | 使用pm2运行： 75 | 76 | cd ~/bin 77 | pm2 start processes.json 78 | 79 | 以太坊（eth或者geth）必须在允许rpc选项的情况下运行： 80 | 81 | geth --rpc 82 | 83 | 在geth下，默认的rpc端口（如果没有指定的话）是8545 84 | 85 | ## 升级 86 | 87 | 要升级API客户端的话就要使用如下的命令： 88 | 89 | ~/bin/www/bin/update.sh 90 | 91 | 这会停止当前的netstats客户端进程，自动检测你的以太坊的安装状态和版本，升级到最新的开发者版本，更新netstats客户端并重新载入进程。 92 | 93 | 94 | -------------------------------------------------------------------------------- /[中文]-RLP.md: -------------------------------------------------------------------------------- 1 | RLP (递归长度前缀)提供了一种适用于任意二进制数据数组的编码，RLP已经成为以太坊中对对象进行序列化的主要编码方式。 RLP的唯一目标就是解决结构体的编码问题；对原子数据类型（比如，字符串，整数型，浮点型）的编码则交给更高层的协议；以太坊中要求数字必须是一个大端字节序的、没有零占位的存储的格式（也就是说，一个整数0和一个空数组是等同的）。 2 | 3 | 对于在 RLP 格式中对一个字典数据的编码问题，有两种建议的方式，一种是通过二维数组表达键值对，比如`[[k1,v1],[k2,v2]...]`，并且对键进行字典序排序；另一种方式是通过以太坊文档中提到的高级的[基数树](https://github.com/ethereum/wiki/wiki/Patricia-Tree) 编码来实现。 4 | 5 | ### 定义 6 | 7 | RLP 编码函数接受一个item。定义如下： 8 | 9 | * 将一个字符串作为一个item（比如，一个 byte 数组） 10 | * 一组item列表（list）作为一个item 11 | 12 | 例如，一个空字符串可以是一个item，一个字符串"cat"也可以是一个item，一个含有多个字符串的列表也行，复杂的数据结构也行，比如这样的`["cat",["puppy","cow"],"horse",[[]],"pig",[""],"sheep"]`。注意在本文后续内容中，说"字符串"的意思其实就相当于"一个确定长度的二进制字节信息数据"；而不要假设或考虑关于字符的编码问题。 13 | 14 | RLP 编码定义如下： 15 | 16 | * 对于 `[0x00, 0x7f]` 范围内的单个字节, RLP 编码内容就是字节内容本身。 17 | * 否则，如果是一个 0-55 字节长的字符串，则RLP编码有一个特别的数值 **0x80** 加上字符串长度，再加上字符串二进制内容。这样，第一个字节的表达范围为 `[0x80, 0xb7]`. 18 | * 如果字符串长度超过 55 个字节，RLP 编码由定值 **0xb7** 加上字符串长度的长度，加上字符串长度长度，加上字符串二进制内容组成。比如，一个长度为 1024 的字符串，将被编码为`\xb9\x04\x00` 后面再加上字符串内容。第一字节的表达范围是`[0xb8, 0xbf]`。 19 | * 如果列表的内容（它的所有项的组合长度）是0-55个字节长，它的RLP编码由0xC0加上所有的项的RLP编码串联起来的长度得到的单个字节，后跟所有的项的RLP编码的串联组成。 第一字节的范围因此是[0xc0, 0xf7] 20 | * 如果列表的内容超过55字节，它的RLP编码由0xC0加上所有的项的RLP编码串联起来的长度的长度得到的单个字节，后跟所有的项的RLP编码串联起来的长度的长度，再后跟所有的项的RLP编码的串联组成。 第一字节的范围因此是[0xf8, 0xff] 。 21 | 22 | 用Python代码表达以上逻辑: 23 | 24 | ```python 25 | def rlp_encode(input): 26 | if isinstance(input,str): 27 | if len(input) == 1 and chr(input) < 128: return input 28 | else: return encode_length(len(input),128) + input 29 | elif isinstance(input,list): 30 | output = '' 31 | for item in input: output += rlp_encode(item) 32 | return encode_length(len(output),192) + output 33 | 34 | def encode_length(L,offset): 35 | if L < 56: 36 | return chr(L + offset) 37 | elif L < 256**8: 38 | BL = to_binary(L) 39 | return chr(len(BL) + offset + 55) + BL 40 | else: 41 | raise Exception("input too long") 42 | 43 | def to_binary(x): 44 | return '' if x == 0 else to_binary(int(x / 256)) + chr(x % 256) 45 | ``` 46 | 47 | ### 例子 48 | 49 | 字符串 "dog" = [ 0x83, 'd', 'o', 'g' ] 50 | 51 | 列表 [ "cat", "dog" ] = `[ 0xc8, 0x83, 'c', 'a', 't', 0x83, 'd', 'o', 'g' ]` 52 | 53 | 空字符串 ('null') = `[ 0x80 ]` 54 | 55 | 空列表 = `[ 0xc0 ]` 56 | 57 | 数字15 ('\x0f') = `[ 0x0f ]` 58 | 59 | 数字 1024 ('\x04\x00') = `[ 0x82, 0x04, 0x00 ]` 60 | 61 | The [set theoretical representation](http://en.wikipedia.org/wiki/Set-theoretic_definition_of_natural_numbers) of two, `[ [], [[]], [ [], [[]] ] ] = [ 0xc7, 0xc0, 0xc1, 0xc0, 0xc3, 0xc0, 0xc1, 0xc0 ]` 62 | 63 | 字符串 "Lorem ipsum dolor sit amet, consectetur adipisicing elit" = `[ 0xb8, 0x38, 'L', 'o', 'r', 'e', 'm', ' ', ... , 'e', 'l', 'i', 't' ]` 64 | -------------------------------------------------------------------------------- /pages/rlp/[chinese]-rlp.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: RLP 3 | category: 4 | --- 5 | 6 | RLP (递归长度前缀)提供了一种适用于任意二进制数据数组的编码，RLP已经成为以太坊中对对象进行序列化的主要编码方式。 RLP的唯一目标就是解决结构体的编码问题；对原子数据类型（比如，字符串，整数型，浮点型）的编码则交给更高层的协议；以太坊中要求数字必须是一个大端字节序的、没有零占位的存储的格式（也就是说，一个整数0和一个空数组是等同的）。 7 | 8 | 对于在 RLP 格式中对一个字典数据的编码问题，有两种建议的方式，一种是通过二维数组表达键值对，比如`[[k1,v1],[k2,v2]...]`，并且对键进行字典序排序；另一种方式是通过以太坊文档中提到的高级的[基数树](./Patricia-Tree) 编码来实现。 9 | 10 | ### 定义 11 | 12 | RLP 编码函数接受一个item。定义如下： 13 | 14 | * 将一个字符串作为一个item（比如，一个 byte 数组） 15 | * 一组item列表（list）作为一个item 16 | 17 | 例如，一个空字符串可以是一个item，一个字符串"cat"也可以是一个item，一个含有多个字符串的列表也行，复杂的数据结构也行，比如这样的`["cat",["puppy","cow"],"horse",[[]],"pig",[""],"sheep"]`。注意在本文后续内容中，说"字符串"的意思其实就相当于"一个确定长度的二进制字节信息数据"；而不要假设或考虑关于字符的编码问题。 18 | 19 | RLP 编码定义如下： 20 | 21 | * 对于 `[0x00, 0x7f]` 范围内的单个字节, RLP 编码内容就是字节内容本身。 22 | * 否则，如果是一个 0-55 字节长的字符串，则RLP编码有一个特别的数值 **0x80** 加上字符串长度，再加上字符串二进制内容。这样，第一个字节的表达范围为 `[0x80, 0xb7]`. 23 | * 如果字符串长度超过 55 个字节，RLP 编码由定值 **0xb7** 加上字符串长度的长度，加上字符串长度长度，加上字符串二进制内容组成。比如，一个长度为 1024 的字符串，将被编码为`\xb9\x04\x00` 后面再加上字符串内容。第一字节的表达范围是`[0xb8, 0xbf]`。 24 | * 如果列表的内容（它的所有项的组合长度）是0-55个字节长，它的RLP编码由0xC0加上所有的项的RLP编码串联起来的长度得到的单个字节，后跟所有的项的RLP编码的串联组成。 第一字节的范围因此是[0xc0, 0xf7] 25 | * 如果列表的内容超过55字节，它的RLP编码由0xC0加上所有的项的RLP编码串联起来的长度的长度得到的单个字节，后跟所有的项的RLP编码串联起来的长度的长度，再后跟所有的项的RLP编码的串联组成。 第一字节的范围因此是[0xf8, 0xff] 。 26 | 27 | 用Python代码表达以上逻辑: 28 | 29 | ```python 30 | def rlp_encode(input): 31 | if isinstance(input,str): 32 | if len(input) == 1 and chr(input) < 128: return input 33 | else: return encode_length(len(input),128) + input 34 | elif isinstance(input,list): 35 | output = '' 36 | for item in input: output += rlp_encode(item) 37 | return encode_length(len(output),192) + output 38 | 39 | def encode_length(L,offset): 40 | if L < 56: 41 | return chr(L + offset) 42 | elif L < 256**8: 43 | BL = to_binary(L) 44 | return chr(len(BL) + offset + 55) + BL 45 | else: 46 | raise Exception("input too long") 47 | 48 | def to_binary(x): 49 | return '' if x == 0 else to_binary(int(x / 256)) + chr(x % 256) 50 | ``` 51 | 52 | ### 例子 53 | 54 | 字符串 "dog" = [ 0x83, 'd', 'o', 'g' ] 55 | 56 | 列表 [ "cat", "dog" ] = `[ 0xc8, 0x83, 'c', 'a', 't', 0x83, 'd', 'o', 'g' ]` 57 | 58 | 空字符串 ('null') = `[ 0x80 ]` 59 | 60 | 空列表 = `[ 0xc0 ]` 61 | 62 | 数字15 ('\x0f') = `[ 0x0f ]` 63 | 64 | 数字 1024 ('\x04\x00') = `[ 0x82, 0x04, 0x00 ]` 65 | 66 | The [set theoretical representation](http://en.wikipedia.org/wiki/Set-theoretic_definition_of_natural_numbers) of two, `[ [], [[]], [ [], [[]] ] ] = [ 0xc7, 0xc0, 0xc1, 0xc0, 0xc3, 0xc0, 0xc1, 0xc0 ]` 67 | 68 | 字符串 "Lorem ipsum dolor sit amet, consectetur adipisicing elit" = `[ 0xb8, 0x38, 'L', 'o', 'r', 'e', 'm', ' ', ... , 'e', 'l', 'i', 't' ]` 69 | -------------------------------------------------------------------------------- /Home.md: -------------------------------------------------------------------------------- 1 | # Ethereum Classic 2 | 3 | Ethereum Classic is a community building and supporting __Ethereum__ technologies and protocols. Ethereum Classic's origin relative to the [Ethereum Foundation](https://www.ethereum.org/foundation) came as a rejection the [EF DAO bailout](http://fintechist.com/ethereum-classic-gains-support-wake-dao-bailout/) in June 2016. Since then, Ethereum Classic has grown into it's own, forging paths in some ways parallel and in others divergent from it's hard-forked younger brother. 4 | 5 | Etherum Classic's exchange ticker is __ETC__. 6 | 7 | Ethereum Classic's core development team is __ETCDEV__, working alongside an immensely generous and capable community, to build and maintain a wide variety of projects. 8 | 9 | :books: This is a _wiki_: Users signed in with GitHub can edit and add pages using the [browser](https://help.github.com/articles/editing-wiki-pages-via-the-online-interface) or [locally](https://help.github.com/articles/adding-and-editing-wiki-pages-locally). 10 | 11 | ## Status 12 | 13 | ### Homestead 14 | 15 | Version 1.0 of Ethereum aka Frontier was released on July 30th 2015! Development continues towards the versions named Homestead, Metropolis and Serenity (v1.1). Frontier is aimed at exchangers and [miners](./Mining). Homestead is aiming for [Ðapps developers](./Ethereum-Development-Tutorial), while Metropolis is aiming for end users with the release of the Mist browser. Serenity is meant to move from consensus through [Proof-of-Work](./Ethash) to [Proof-of-Stake](https://blog.ethereum.org/2015/08/01/introducing-casper-friendly-ghost/). 16 | 17 | ## Getting started 18 | To get the basic concepts of Ethereum visit the Ethereum homepage over at [http://ethereum.org](http://ethereum.org/). If you want to get a deeper understanding, start by read the [whitepaper](./White-Paper) and the [design rationale](./Design-Rationale). For a more formal review, read the [yellow paper](http://gavwood.com/Paper.pdf). See the [development tutorial](./Ethereum-Development-Tutorial) for quick start to developing smart contracts. 19 | 20 | ## Don't get lost 21 | Check the [Glossary](./Glossary) and our [FAQ](./FAQ). There are separate wikis for information relevant to the [C++](https://github.com/ethereumproject/cpp-ethereum/wiki) and [Go](https://github.com/ethereumproject/go-ethereum/wiki) implementations (Python and Javascript coming soon), 22 | 23 | ## Downloads 24 | Bleeding edge code can be cloned from the develop branch of their git repositories: 25 | 26 | - https://github.com/ethereumproject/cpp-ethereum 27 | - https://github.com/ethereumproject/go-ethereum 28 | - https://github.com/ethereumproject/pyethapp 29 | 30 | 31 | To see the state of the latest Ethereum builds, see the [build server](http://build.ethdev.com/console). 32 | -------------------------------------------------------------------------------- /URL-Hint-Protocol.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: URL Hint Protocol 3 | category: 4 | --- 5 | 6 | There exists a root `Registry` contract at address 0x42 (this is the auctioning thing). There exists a contract interface, `register`, which `Registry` implements. 7 | 8 | Entries in `register`, when looked up (indexed by a string32 name) have several value fields, including `content` and `register`. 9 | 10 | `content` is the content hash which gets loaded when you enter this name into Mist/AZ. 11 | 12 | `register` is the address of a subregistry contract (some contract implementing `register`) which gets queried recursively. 13 | 14 | ### Example 15 | 16 | - `eth://gavofyork` results in the main Registry (at 0x42) being queried for the entry `gavofyork`. The content field of this entry (a SHA3 hash of a zip file OR manifest) is used to display content (see Content section for more info). 17 | 18 | ## URL Composition 19 | 20 | All URLs canonically begin `eth://` and are a number of components, each separated by a `/`. The field `register` is used to do a recursive lookup. 21 | 22 | So the components of `gavofyork/tools/site/contact` would comprise four components, in order: `gavofyork`, `tools`, `site`, `contact`. 23 | 24 | Any periods `.` before the left-most slash `/` delineate components which are specified in reverse order. 25 | 26 | So non-canonical forms of the above address are: 27 | 28 | - `tools.gavofyork/site/contact` 29 | - `site.tools.gavofyork/contact` 30 | - `contact.site.tools.gavofyork` 31 | 32 | NOTE: any periods after the leftmost `/` are treated no differently than other alphanumeric characters. 33 | 34 | ### Example 35 | 36 | - `eth://gavofyork/site` results in the main Registry (at 0x42) being queried for the entry `gavofyork`. The register field of this entry (an address of a `register`-implementing contract) is then queried for the entry `site`. The `content` field of this entry is used to display content. 37 | 38 | # Content 39 | 40 | Normally Swarm would be used to determine the content from the content hash. 41 | 42 | For 1.0, this will not be possible, so we will fall back to using HTTP distribution. To enable this we will include one or many URLHint contracts, which provide hints of URLs that allow downloading of particular content hashes. Find the contract in dapp-bin. 43 | 44 | The content downloaded should be treated in many ways (and hashed) to discover what the content is. Possible ways include base 64 encoding, hex encoding and raw, and any content-cropping needed (e.g. a HTML page should have everything up to body tags removed). 45 | 46 | It will be up to the dapp/content uploader to keep URLHint entries updated. 47 | 48 | The address of the URLHint contract will be specified on an ad-hoc basis and users will be able to enter additional ones into their browser. 49 | 50 | -------------------------------------------------------------------------------- /[Japanese]--License.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: License 3 | category: 4 | --- 5 | 6 | Overview 7 | 8 | The Ethereum Foundation ensures three principles concerning the funds it uses to develop Ethereum: 9 | 10 | - it is both open source software and Free software after the definition of the Free Software Foundation (so-called FOSS); 11 | - no special treatment is given to any single entity concerning the copyright of the software, the Foundation included; 12 | - source-code will not be distributed ahead of binaries. 13 | 14 | However, this is not where the story ends; there are many different licences available that conform to these rules. After considerable discussion, both internal and external together with The Ethereum software collection is distributed under several licences, partly to reflect the different thinking of the minds behind different pieces of software and partly to reflect the need to adapt to real-world issues and opportunities and lay out a strategy to provide the best possible future for the Ethereum community. 15 | 16 | ### The Core 17 | 18 | Ethereum の core (核となる部分)には、分散型大衆決定マシンのエンジンとネットワークを担うコードとethereumをサポートする 19 | 全てのライブラリが含まれています。: 20 | * libethereum 21 | * libp2p 22 | * libdevcore 23 | * libethcore 24 | * livevm 25 | * libevmface 26 | 27 | Ethereum core は、最もライセンスフリーである概念のもとでリリース予定であり、できるだけ多様な環境で Ethereum が使用されること願っております。閉鎖的な環境においてリリースされる、修正や拡張が必要な場合においても、同様に、フリーソフトとして使用していただくことを願っております。 28 | 29 | In this way, while we have not arrived at a final licence, we expect to select one of the MIT licence, the MPL licence or the LGPL licence. If the latter is chosen, it will come with an amendment allowing it to be linked to be statically linked to software for which source code is not available. 30 | 31 | In this way, the core of Ethereum, be it C++ or Go, will be available for use in any commercial environment, closed or open source. 32 | 33 | ### The Applications 34 | 35 | Ethereum の application は以下を含め、GNUライセンスのもとで配布予定です。 36 | * Solidityコンパイラ ( Libsolidity , solc ) 37 | * AlethZero 38 | * Mix 39 | 40 | This is to reflect the fact that these pieces of software tend to not, by nature, need to be amalgamated or augmented into a larger, closed-source, whole. There is however, much to be gained through many different members of the Ethereum-community being incentivised to develop on and build out such software. 41 | 42 | In this way we hope our initial version of Solidity and Mix lay down the foundation for others to build upon and improve in the true Free/open-source software manner. 43 | 44 | ### The Middleware 45 | 46 | Ethereum の middleware は、以下の３つを含み、Affero licence のもとで配布予定です。これはLGPライセンスの一種のようなものです。 47 | * Javascriptで書かれた ethereum.js 48 | * webthree libraries 49 | * eth (command line client) 50 | 51 | We wish to allow free development of technologies by allowing linking to arbitrary software, but again would like to incentivise feeding of back-end integration work back into the community, especially regarding the interoperability with legacy systems. -------------------------------------------------------------------------------- /Licensing.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Licensing 3 | category: 4 | --- 5 | 6 | Overview 7 | 8 | The Ethereum Foundation ensures three principles concerning the funds it uses to develop Ethereum: 9 | 10 | - it is both open source software and Free software after the definition of the Free Software Foundation (so-called FLOSS); 11 | - no special treatment is given to any single entity concerning the copyright of the software, the Foundation included; 12 | - source-code will not be distributed ahead of binaries. 13 | 14 | However, this is not where the story ends; there are many different licenses available that conform to these rules. After considerable discussion, both internal and external together with The Ethereum software collection is distributed under several licenses, partly to reflect the different thinking of the minds behind different pieces of software and partly to reflect the need to adapt to real-world issues and opportunities and lay out a strategy to provide the best possible future for the Ethereum community. 15 | 16 | ### The Core 17 | 18 | The core of Ethereum includes the consensus engine, the networking code and any supporting libraries. For C++, this includes libethereum, libp2p, libdevcore, libdevcrypto, libethcore, libevm and libevmface. 19 | 20 | The core of Ethereum will be released under the most liberal of licenses. This reflects our desire to have Ethereum used in as many diverse environments as possible, even those which, for various reasons can require modifications or augmentations to the software which cannot be released to the public. 21 | 22 | In this way, while we have not arrived at a final license, we expect to select one of the MIT license, the MPL license or the LGPL license. If the latter is chosen, it will come with an amendment allowing it to be linked to be statically linked to software for which source code is not available. 23 | 24 | In this way, the core of Ethereum, be it C++ or Go, will be available for use in any commercial environment, closed or open source. 25 | 26 | ### The Applications 27 | 28 | The applications of Ethereum, including the Solidity compiler (libsolidity, solc), AlethZero and Mix will be distributed under the GNU General Public License. This is to reflect the fact that these pieces of software tend to not, by nature, need to be amalgamated or augmented into a larger, closed-source, whole. There is however, much to be gained through many different members of the Ethereum-community being incentivised to develop on and build out such software. 29 | 30 | In this way we hope our initial version of Solidity and Mix lay down the foundation for others to build upon and improve in the true Free/open-source software manner. 31 | 32 | ### The Middleware 33 | 34 | The middleware of Ethereum, including the Javascript-based ethereum.js, the webthree libraries and eth (the command line client) will be distributed under an Affero license, likely the LGPL variant of it. We wish to allow free development of technologies by allowing linking to arbitrary software, but again would like to incentivise feeding of back-end integration work back into the community, especially regarding the interoperability with legacy systems. -------------------------------------------------------------------------------- /pages/rlp/[japanese]-rlp.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: RLP 3 | category: 4 | --- 5 | 6 | RLPの目的は任意のネストされたバイナリデータをエンコードすることです。RLPはEthereumにおいてシリアライズされたオブジェクトをエンコードするメインの方法です。RLPの目的は構造をエンコードすることです:特殊なアトミックなデータ型(例えば文字列型、整数型、浮動小数点型)のエンコードはもっと上位のプロトコルに任せます；Ethereumでは整数型は先頭のゼロが無いビッグエンディアンのバイナリで表されます(よって、整数型のゼロは空のバイトアレイとなります)。 7 | 8 | もし辞書をエンコードするのにRLPを使いたいと思うならば、二つの正規のフォームが使えます。`[[k1,v1],[k2,v2]...]`のような辞書順にならんだキーを使用する方法と、Ethereumで使用されている上位の[Patricia Tree](./Patricia-Tree)を用いたエンコードを使用する方法です。 9 | 10 | 11 | ### 定義 12 | 13 | RLP符号化関数はアイテムを受け入れます。アイテムは以下のように定義されます: 14 | 15 | * 文字列型(すなわちバイトアレイ)はアイテムである 16 | * アイテムのリストはアイテムである 17 | 18 | 例えば、空の文字列はアイテムです。同様に "cat"という単語による文字列もアイテムです。任意の個数の文字列型のリストもアイテムです。そして、`["cat",["puppy","cow"],"horse",[[]],"pig",[""],"sheep"]`のようなもっと複雑なデータ構造もアイテムです。この論説の残りの部分の文脈において、"文字列型"は"あるバイト数のバイナリデータ"と同義語であることに注意しましょう; 特殊なエンコードは用いられておらず、文字列型の内容が何を意味しているかの知識は必要ではありません。 19 | 20 | RLPエンコーディング(符号化)は以下のように定義されます: 21 | 22 | * `[0x00, 0x7f]`の間にある１バイトの値は、そのバイトがそのまま自分自身のRLPエンコーディングとなります。 23 | * もし、文字列が0-55バイトの長さの場合は、RLPエンコーディングは**0x80**と文字列の長さを足した1バイトと、その後に続く文字列で構成されます。よって、最初の1バイトは`[0x80, 0xb7]`の範囲となります。 24 | * もし文字列が55バイトより長い場合、RLPエンコーディングは以下の3つで構成されます。 25 | 文字列の長さをバイナリで表した時に必要となるバイト数を**0xb7**に足した値の1バイト。 26 | 続けて、文字列の長さ、それに続く文字列です。 27 | 例えば1024の長さを持つ文字列の場合、 28 | 文字列の表記に10bitつまり2byte必要なので`\xb9`と、1024を表す`\x04 00`により、 29 | `\xb9\x04\x00`となります。 30 | よって、最初の1バイトは`[0xb8, 0xbf]`の範囲となります。 31 | * もし、リストの全ペイロード(すなわち、全てのアイテムを合わせた長さ)が0-55バイトの長さである場合、RLPエンコーディングは、**0xc0**にリストの長さを足した1倍との値と、それに続くアイテムをRLPエンコーディングして続けたもので構成されます。よって、最初の1バイトの範囲は`[0xc0, 0xf7]`となります。 32 | * もし、リストの全ペイロードの長さが55バイト以上の場合、RLPエンコーディングは以下の構成になります。最初に **0xf7** にペイロードの長さをバイナリで表した時に必要となるバイト数を足した1バイト。続けて、ペイロードの長さ。最後にアイテムをRLPエンコーディングした物を続けたものとなります。よって、最初の1バイトの範囲は`[0xf8, 0xff]`となります。 33 | 34 | 35 | コードで表すと以下のようになります： 36 | 37 | ```python 38 | def rlp_encode(input): 39 | if isinstance(input,str): 40 | if len(input) == 1 and chr(input) < 128: return input 41 | else: return encode_length(len(input),128) + input 42 | elif isinstance(input,list): 43 | output = '' 44 | for item in input: output += rlp_encode(item) 45 | return encode_length(len(output),192) + output 46 | 47 | def encode_length(L,offset): 48 | if L < 56: 49 | return chr(L + offset) 50 | elif L < 256**8: 51 | BL = to_binary(L) 52 | return chr(len(BL) + offset + 55) + BL 53 | else: 54 | raise Exception("input too long") 55 | 56 | def to_binary(x): 57 | return '' if x == 0 else to_binary(int(x / 256)) + chr(x % 256) 58 | ``` 59 | 60 | ### 例 61 | 62 | 文字列 "dog" = [ 0x83, 'd', 'o', 'g' ] 63 | 64 | リスト [ "cat", "dog" ] = `[ 0xc8, 0x83, 'c', 'a', 't', 0x83, 'd', 'o', 'g' ]` 65 | 66 | 空文字列 ('null') = `[ 0x80 ]` 67 | 68 | 空リスト = `[ 0xc0 ]` 69 | 70 | 整数 15 ('\x0f') のエンコード = `[ 0x0f ]` 71 | 72 | 整数 1024 ('\x04\x00') のエンコード = `[ 0x82, 0x04, 0x00 ]` 73 | 74 | [ 集合論的表現 ](http://en.wikipedia.org/wiki/Set-theoretic_definition_of_natural_numbers) `[ [], [[]], [ [], [[]] ] ] = [ 0xc7, 0xc0, 0xc1, 0xc0, 0xc3, 0xc0, 0xc1, 0xc0 ]` 75 | 76 | 文字列 "Lorem ipsum dolor sit amet, consectetur adipisicing elit" = `[ 0xb8, 0x38, 'L', 'o', 'r', 'e', 'm', ' ', ... , 'e', 'l', 'i', 't' ]` -------------------------------------------------------------------------------- /Client-Version-Strings.md: -------------------------------------------------------------------------------- 1 | Every client implementation of the Ethereum protocol – along with every version of it – has a *human readable* string identifier. Although this ID is exchanged in the [P2P protocol](https://github.com/ethereum/wiki/wiki/%C3%90%CE%9EVp2p-Wire-Protocol#p2p), it itself isn't used by the protocol for anything, rather it enables easily localizing issues with a particular client, or a particular version of a client. 2 | 3 | Still, there tools popping up that analyze and create various statistics about the network topology itself, which have a hard time conforming to the identifier/versioning schema employed by each implementation. To avoid requiring each such tool to implement a full ID parsing for every type of node in the network, this document outlines a **suggested** schema, part of which would be common among all implementations, and some would be specific to one or the other. This would allow simple tools to properly parse the common information out of each client's ID string, whereas more complex tools might also further inspect the client specific metadata. 4 | 5 | *Please note, this document should be perceived as a guideline at most, and definitely not a golden standard to be enforced by any implementation or tool. The goal is to aid the ecosystem relying on it, but it is not something set in stone.* 6 | 7 | ### Suggested identifier schema 8 | 9 | All identifier strings should be a slash separated list of metadata fields: `metadata-1/metadata-2/.../metadata-n`, where the first few fields are fixed among all clients, whereas the latter ones (both in meaning and in count) are up to each implementation to use as seen fit. 10 | 11 | The fixed fields are: 12 | 1. Display name of the client, without any version numbering 13 | * E.g. `Geth`, `++eth`, `Ethereum(J)` 14 | 2. Semantic version, prefixed with `v`, *optionally* suffixed by `-` 15 | * E.g. `v1.3.3`, `v0.9.41-ed7a8a35`, `v1.4.0-unstable` 16 | 3. Name of the operating system the client is running on 17 | * E.g. `Linux`, `Windows`, `Darwin`, `Android` 18 | 19 | As there might be differences in implementation as to how one language or another retrieves the name of the operating system – among others – we recommend tools using the IDs to convert the strings internally to lowercase before making aggregations. 20 | 21 | A few examples conforming to the above schema spec: 22 | 23 | ``` 24 | Geth/v1.3.3/darwin 25 | ++eth/v0.9.41-ed7a8a35/Windows 26 | Ethereum(J)/v1.0.0/Linux 27 | ``` 28 | 29 | ### Optional extensions 30 | 31 | Beside the above defined fixed metadata fields, an identifier string may contain arbitrarily many implementation specific metadata entries (the order and index of which should desirably be maintained by the developers of said client implementations). To help developers working on analysis tools have a central repository of the metadata semantics, the rest of this document describes the extra fields used by each implementation. Feel free to add your own implementation to the below list, but please maintain alphabetical ordering and please be concise. 32 | 33 | * **Geth**: `` / `` / `` 34 | * `Geth/v1.3.3-c541b38/linux/go1.5.5` 35 | * `Geth/v1.4.0-unstable/android/go1.6beta2/jit/gopher-power` -------------------------------------------------------------------------------- /JSON-RPC-Error-Codes-Improvement-Proposal.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: JSON RPC Error Codes Improvement Proposal 3 | category: 4 | --- 5 | 6 | To help developers add proper error handling in the dapp side, we need to implement custom error codes for the returned JSON RPC errors. 7 | 8 | ## JSON RPC Standard errors 9 | 10 | | Code | Possible Return message | Description | 11 | | --------|-------------------------|-------------| 12 | |-32700 | Parse error | Invalid JSON was received by the server. An error occurred on the server while parsing the JSON text. | 13 | |-32600 | Invalid Request | The JSON sent is not a valid Request object. | 14 | |-32601 | Method not found | The method does not exist / is not available. | 15 | |-32602 | Invalid params | Invalid method parameter(s). | 16 | |-32603 | Internal error | Internal JSON-RPC error. | 17 | |-32000 to -32099 | `Server error`. Reserved for implementation-defined server-errors. | 18 | 19 | ## Custom error codes: 20 | 21 | | Code | Possible Return message | Description | 22 | | --------|-------------------------|-------------| 23 | |1 | Unauthorized | Should be used when some action is not authorized, e.g. sending from a locked account. 24 | |2 | Action not allowed | Should be used when some action is not allowed, e.g. preventing an action, while another depending action is processing on, like sending again when a confirmation popup is shown to the user (?). 25 | |3 | Execution error | Will contain a subset of custom errors in the data field. See below. | 26 | 27 | ### Custom error fields 28 | 29 | Custom error `3` can contain custom error(s) to further explain what went wrong. 30 | They will be contained in the `data` field of the RPC error message as follows: 31 | 32 | ```js 33 | { 34 | code: 3, 35 | message: 'Execution error', 36 | data: [{ 37 | code: 102, 38 | message: 'Innsufficient gas' 39 | }, 40 | { 41 | code: 103, 42 | message: 'Gas limit exceeded' 43 | }] 44 | } 45 | ``` 46 | 47 | | Code | Possible Return message | Description | 48 | | --------|-------------------------|-------------| 49 | |100 | X doesn't exist | Should be used when something which should be there is not found. (Doesn't apply to eth_getTransactionBy* and eth_getBlock*. They return a success with value `null`) 50 | |101 | Requires ether | Should be used for actions which require somethin else, e.g. gas or a value. 51 | |102 | Gas too low | Should be used when a to low value of gas was given. 52 | |103 | Gas limit exceeded | Should be used when a limit is exceeded, e.g. for the gas limit in a block. 53 | |104 | Rejected | Should be used when an action was rejected, e.g. because of its content (too long contract code, containing wrong characters ?, should differ from `-32602` - Invalid params). 54 | |105 | Ether too low | Should be used when a to low value of Ether was given. 55 | 56 | 57 | ## Possible future error codes? 58 | 59 | | Code | Possible Return message | Description | 60 | | --------|-------------------------|-------------| 61 | |106 | Timeout | Should be used when an action timedout. 62 | |107 | Conflict | Should be used when an action conflicts with another (ongoing?) action. -------------------------------------------------------------------------------- /Layers.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Layers 3 | category: 4 | --- 5 | 6 | ## Networking daemon 7 | 8 | Purpose: the networking daemon must be able to connect to other Ethereum nodes, and accept and share data, so as to serve as the backbone for the Ethereum network. The daemon itself should be as neutral as possible; ideally, it should be useful as part of any currency or cryptographic protocol without modification. It should include anti-DDoS features; perhaps maintain a running score preventing any single IP from making more than one request per second. 9 | 10 | Interface: 11 | 12 | 1. every time the daemon receives a new message (ie. H(M) is not equal to H(Mprev) for any Mprev received previously), it should send a POST request to http://localhost: containing the data, where outputport can be set in the ~/.ethereum/ethereum.conf file (default 1242 if not set) 13 | 2. the daemon should listen on port , where inputport can be set in the ~/.ethereum/ethereum.conf file (default 1243 if not set), and if it receives a message in a post request it should push the data out to all connected nodes in the network. 14 | Dependencies: internet, bootstrapping nodes 15 | 16 | ## Ethereum Core 17 | 18 | ### Communication layer 19 | 20 | 1. Process_network_message(string) -> msg or transaction or block 21 | 2. Create_network_message 22 | 23 | ### IO Layer (ie. usually database) 24 | 25 | 1. Insert object(value) (key = sha256(value)) 26 | 2. Get object (key) -> value 27 | 28 | ### Data layer 29 | 30 | 1. get_transaction 31 | 2. get_block 32 | 3. get_address_balance / nonce 33 | 4. get_contract_memory_at_index 34 | 5. get_contract_root 35 | 6. get_object (Merkle trie nodes, etc) 36 | 7. block class 37 | 8. transaction class 38 | 39 | ### Manager 40 | 41 | 1. get_latest_block 42 | 2. add_block (including validation and total difficulty calculation) 43 | 3. apply_transactions_to_block (for miners) 44 | 45 | ### Application Layer 46 | 47 | 1. Wallet 48 | 2. Full 49 | 3. SPV 50 | 4. Graphical block explorer 51 | 5. Miner 52 | 53 | ## Classes 54 | 55 | ### Block class 56 | 57 | Purpose: the block class should be able to parse blocks, serialize blocks and handle certain updating operations to blocks. 58 | 59 | Interface: 60 | 61 | 1. deserialize: string -> void (constructor) 62 | 2. get_balance: number address -> number 63 | 3. get_contract_state: number address, number index -> number 64 | 4. update_balance: number address, number newbalance -> void 65 | 5. update_contract_state: number address, number index, number newvalue -> void 66 | 6. get_contract_size: number address -> number 67 | 7. serialize: void -> string 68 | 69 | ### Transaction class 70 | 71 | Purpose: the transaction class should be able to parse transactions, sign transactions and serialize transactions. Note that the serialize method should fail for transactions without a signature; transactions that are created inside a block and not deserialized should never actually be stored or serialized in any form. 72 | 73 | Interface: 74 | 75 | 1. deserialize: string -> void (constructor) 76 | 2. sign: privkey -> void 77 | 3. serialize: void -> string 78 | 4. create: number address, number value, number fee, array[number] data -> void (constructor) 79 | 5. hash: void -> number 80 | 6. to, from, value, fee, data (accessible and settable member variables) 81 | -------------------------------------------------------------------------------- /[Romanian]-Layers.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Layers 3 | category: 4 | --- 5 | 6 | ###Layers 7 | 8 | Networking daemon 9 | 10 | Scop:networking daemon trebuie sa se poata conecta la alte noduri Ethereum, si sa accepte si sa imparta datele, pentru a servi drept coloana de sprijin pentru reteaua Ethereum. Daemon-ul in sine trebuie sa fie cat mai neutru posibil; ideal ar trebui sa fie util ca parte a oricarei valute sau protocol cryptographic fara modificari. Trebuie sa includa trasaturi anti DDoS, si poate sa mentina un running score care sa previna orice IP singur de a face mai mult de un request pe secunda. 11 | Interfata: 12 | 1. De fiecare data cand Daemon-ul primeste un nou mesaj (i.e. H(M) nu este egal cu H(Mprev) pentru orice Mprev primit anterior), ar trebui sa trimita o cerere POST la http://localhost: containing the data, unde outputport poate fi setat in fisierul ~/.ethereum/ethereum.conf (1242 implicit, in cazul in care nu este setat) 13 | 2. the daemon should listen on port, unde inputport poate fi setat in fisierul ~/.ethereum/ethereum.conf (1243 implicit, daca nu este setat), si daca primeste un mesaj intr-un post care il solicita ar trebui sa impinga datele spre toate nodurile conectate ale retelei. Dependente: internet, noduri bootstrapping 14 | 15 | 16 | Ethereum Core 17 | 18 | Layer de comunicare (Communication Layer) 19 | 20 | 1.Process_network_message(sir) -> msg sau tranzactie sau block 21 | 2.Create_network_message 22 | 23 | IO Layer (ie. De obicei baza de date) 24 | 25 | 1. Insert object(value) (key = sha256(value)) 26 | 2. Get object (key) -> value 27 | Data layer 28 | 1. get_transaction 29 | 2. get_block 30 | 3. get_address_balance / nonce 31 | 4. get_contract_memory_at_index 32 | 5. get_contract_root 33 | 6. get_object (Merkle trie nodes, etc) 34 | 7. block class 35 | 8. transaction class 36 | Manager 37 | 1. get_latest_block 38 | 2. add_block (including validation and total difficulty calculation) 39 | 3. apply_transactions_to_block (for miners) 40 | Application Layer 41 | 1. Wallet 42 | 2. Full 43 | 3. SPV 44 | 4. Graphical block explorer 45 | 5. Miner 46 | Clase 47 | Clasa Block 48 | Scop: clasa block trebuia sa poata analiza block-uri, sa le serializeze si sa poata manipula anumite operatiuni de actualizare la block-uri. 49 | Interfata: 50 | Interface: 51 | 1. deserialize: string -> void (constructor) 52 | 2. get_balance: number address -> number 53 | 3. get_contract_state: number address, number index -> number 54 | 4. update_balance: number address, number newbalance -> void 55 | 5. update_contract_state: number address, number index, number newvalue -> void 56 | 6. get_contract_size: number address -> number 57 | 7. serialize: void -> string 58 | Clasa Tranzactii 59 | Scop: clasa tranzactii trebuie sa poata analiza tranzactiile, sa le semneze si sa le serializeze. Retineti ca metoda de serializare poate esua pentru tranzactii fara semnatura, tranzactiile care sunt create intr-un block si nu sunt deserializate nu ar trebui sa fie, de fapt, serializate sau stocate, in nici o forma. 60 | Interfata: 61 | 1. deserialize: string -> void (constructor) 62 | 2. sign: privkey -> void 63 | 3. serialize: void -> string 64 | 4. create: number address, number value, number fee, array[number] data -> void (constructor) 65 | 5. hash: void -> number 66 | 6. to, from, value, fee, data (accessible and settable member variables) 67 | -------------------------------------------------------------------------------- /Whisper-PoC-2-Wire-Protocol.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Whisper PoC-2 Wire Protocol 3 | category: 4 | --- 5 | 6 | Peer-to-peer communications between nodes running Whisper clients run using the underlying [ÐΞVp2p Wire Protocol](./%C3%90%CE%9EVp2p-Wire-Protocol). 7 | 8 | This is a preliminary wire protocol for the Whisper subsystem. It will change. 9 | 10 | ### Whisper Sub-protocol 11 | 12 | **Status** 13 | [`+0x00`: `P`, `protocolVersion`: `P`] Inform a peer of the **whisper** status. This message should be send _after_ the initial handshake and _prior_ to any **whisper** related messages. 14 | * `protocolVersion` is one of: 15 | * `0x02` for PoC-7. 16 | 17 | **Messages** 18 | [`+0x01`: `P`, [`expiry1`: `P`, `ttl1`: `P`, [`topic1x1`: `B_4`, `topic1x2`: `B_4`, ...], `data1`: `B`, `nonce1`: `P`], [`expiry2`: `P`, ...], ...] Specify one or more messages. Nodes should not resend the same message to a peer in the same session, nor send a message back to a peer from which it received. This packet may be empty. The packet must be sent at least once per second, and only after receiving a **Messages** message from the peer. 19 | 20 | **TopicFilter** 21 | [`+0x02`: `P`, `bloom`: `B_64`] Specify the bloom filter of the topics that the sender is interested in. The bloom method is defined below. 22 | 23 | ### Session Management 24 | 25 | For the Whisper sub-protocol, upon an active session, a `Status` message must be sent. Following the reception of the peer's `Status` message, the Whisper session is active. The peer with the greatest Node Id should send a **Messages** message to begin the message rally. From that point, peers take it in turns to send (possibly empty) Messages packets. 26 | 27 | ### Topics and Abridged Topics 28 | 29 | *Topics* are 32-byte hashes, typically generated from ÐApp-specified data. The *abridged topic* is the first 4 bytes of the topic. Abridged topics allow the identification (within the bounds of an acceptably high probability) of a given topic, useful for determining the utility of a topic for a given peer, yet do not give away the full topic information itself, allowing it to be used as a strong encryption key whose secret is not inherently available. 30 | 31 | ### Bloomed Topics 32 | 33 | The Bloom filter used in the `TopicFilter` message type is a means a identifying a number of topics to a peer without compromising (too much) privacy over precisely what topics are of interest. Precise control over the information content (and thus efficiency of the filter) may be maintained through the addition of bits. 34 | 35 | Blooms are formed by the bitwise OR operation on a number of bloomed topics. The bloom function takes the abridged topic (the first four bytes of the SHA3 of the ÐApp/user level topic description) and projects them onto a 512-bit slice; in total, three bits are marked for each bloomed topic. 36 | 37 | The projection function is defined as a mapping from a a 4-byte slice `S` to a 512-bit slice `D`; for ease of explanation, `S` will dereference to bytes, whereas `D` will dereference to bits. 38 | 39 | ``` 40 | LET D[*] = 0 41 | FOREACH i IN { 0, 1, 2 } DO 42 | LET n = S[i] 43 | IF S[3] & (2 ** i) THEN n += 512 44 | D[n] = 1 45 | END FOR 46 | ``` 47 | 48 | In formal notation: 49 | ``` 50 | D[i] := f(0) == i || f(1) == i || f(2) == i 51 | ``` 52 | where: 53 | ``` 54 | f(x) := S[x] + S[3][x] * 512 55 | ``` 56 | (assuming a byte value `S[i]` may be further dereferenced into a bit value) 57 | 58 | -------------------------------------------------------------------------------- /Solidity-Changelog.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Solidity Changelog 3 | category: 4 | --- 5 | 6 | * Improved error messages for unexpected tokens. 7 | 8 | ### 0.1.6 (2015-10-16) 9 | 10 | * `.push()` for dynamic storage arrays. 11 | * Tuple expressions (`(1,2,3)` or `return (1,2,3);`) 12 | * Declaration and assignment of multiple variables (`var (x,y,) = (1,2,3,4,5);` or `var (x,y) = f();`) 13 | * Destructuring assignment (`(x,y,) = (1,2,3)`) 14 | * Bugfix: Internal error about usage of library function with invalid types. 15 | * Bugfix: Correctly parse `Library.structType a` at statement level. 16 | * Bugfix: Correctly report source locations of parenthesized expressions (as part of "tuple" story). 17 | 18 | ### 0.1.5 (2015-10-07) 19 | 20 | * Breaking change in storage encoding: Encode short byte arrays and strings together with their length in storage. 21 | * Report warnings 22 | * Allow storage reference types for public library functions. 23 | * Access to types declared in other contracts and libraries via `.`. 24 | * Version stamp at beginning of runtime bytecode of libraries. 25 | * Bugfix: Problem with initialized string state variables and dynamic data in constructor. 26 | * Bugfix: Resolve dependencies concerning `new` automatically. 27 | * Bugfix: Allow four indexed arguments for anonymous events. 28 | * Bugfix: Detect too large integer constants in functions that accept arbitrary parameters. 29 | 30 | ### 0.1.4 (2015-09-30) 31 | 32 | * Bugfix: Returning fixed-size arrays. 33 | * Bugfix: combined-json output of solc. 34 | * Bugfix: Accessing fixed-size array return values. 35 | * Bugfix: Disallow assignment from literal strings to storage pointers. 36 | * Refactoring: Move type checking into its own module. 37 | 38 | ### 0.1.3 (2015-09-25) 39 | 40 | * `throw` statement. 41 | * Libraries that contain functions which are called via CALLCODE. 42 | * Linker stage for compiler to insert other contract's addresses (used for libraries). 43 | * Compiler option to output runtime part of contracts. 44 | * Compile-time out of bounds check for access to fixed-size arrays by integer constants. 45 | * Version string includes libevmasm/libethereum's version (contains the optimizer). 46 | * Bugfix: Accessors for constant public state variables. 47 | * Bugfix: Propagate exceptions in clone contracts. 48 | * Bugfix: Empty single-line comments are now treated properly. 49 | * Bugfix: Properly check the number of indexed arguments for events. 50 | * Bugfix: Strings in struct constructors. 51 | 52 | ### 0.1.2 (2015-08-20) 53 | 54 | * Improved commandline interface. 55 | * Explicit conversion between `bytes` and `string`. 56 | * Bugfix: Value transfer used in clone contracts. 57 | * Bugfix: Problem with strings as mapping keys. 58 | * Bugfix: Prevent usage of some operators. 59 | 60 | ### 0.1.1 (2015-08-04) 61 | 62 | * Strings can be used as mapping keys. 63 | * Clone contracts. 64 | * Mapping members are skipped for structs in memory. 65 | * Use only a single stack slot for storage references. 66 | * Improved error message for wrong argument count. (#2456) 67 | * Bugfix: Fix comparison between `bytesXX` types. (#2087) 68 | * Bugfix: Do not allow floats for integer literals. (#2078) 69 | * Bugfix: Some problem with many local variables. (#2478) 70 | * Bugfix: Correctly initialise `string` and `bytes` state variables. 71 | * Bugfix: Correctly compute gas requirements for callcode. 72 | 73 | ### 0.1.0 (2015-07-10) 74 | -------------------------------------------------------------------------------- /[Italian]-Impostare-il-proprio-ambiente-di-sviluppo-Ethereum.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Impostare il proprio ambiente di sviluppo Ethereum 3 | category: 4 | --- 5 | 6 | Lo sviluppo su Ethereum e’ stato concepito per essere estremamente facile da imparare per gli sviluppatori – e i linguaggi di programmazione sono abbastanza simili allo Javascript che chiunque conosca quel linguaggio dovrebbe acquisirne padronanza piuttosto velocemente. 7 | 8 | Ci sono tre programmi che ogni sviluppatore dovrebbe scaricare – Alethzero, Mist e Mix. 9 | 10 | * **Alethzero** e’ un client a interfaccia grafica con caratteristiche avanzate come chain private, force mining e una webkit suite completa. 11 | 12 | * **Mist** e’ il browser delle Dapp e il client per il mining nel quale gli utenti accederanno alle vostre Dapps. 13 | 14 | * Infine, **Mix** e’ un ambiente di sviluppo integrato – concepito appositamente per sviluppare e debuggare i contratti e i loro corrispettivi front-end. 15 | 16 | ## Requisiti software: 17 | 18 | Impostare un ambiente di sviluppo dovrebbe essere abbastanza semplice per chiunque ha mai progettato una pagina web prima d’ora – abbiamo tre programmi specifici che dovreste scaricare: 19 | 20 | In primo luogo, [scaricate](https://github.com/ethereumproject/cpp-ethereum/wiki) l’ultima versione stabile di Alethzero, il nostro client scritto in C++, e installatelo sul vostro sistema operativo. Se avete problemi con l’ultima versione stabile di sviluppo, provate a passare alla versione cutting edge, che dovrebbe risolvere alcuni dei problemi. Se invece scegliete di fare un build della vostra versione, allora le istruzioni sono qui. 21 | 22 | In secondo luogo, installate [Mix](https://github.com/ethereumproject/cpp-ethereum/releases) il nostro ambiente di sviluppo integrato disponibile per Windows e Mac. Se utilizzate Linux, seguite le istruzioni qui per installare Mix. 23 | 24 | Infine, installate [Mist](https://github.com/ethereumproject/go-ethereum#automated-dev-builds) per testare le vostre Dapps e calibrare i vostri front-end a mano a mano che li sviluppate. 25 | 26 | ## Extras 27 | 28 | Un text editor o Mix puo’ essere utilizzato per creare il codice backend dei contratti che scriveremo. Per il linguaggio Serpent vi suggeriamo di programmare il vostro editor affinche’ consideri i contratti scritti in Serpent e salvati con il suffisso ‘.se’ come sintassi python e per il linguaggio Solidity vi consigliamo di salvare i files con il suffisso ‘.sol’. 29 | 30 | Il live refresh non e’ raccomandato mentre lavorate sulla vostra front-end in html, dato che non e’ stato testato appieno. 31 | 32 | ## Installare Alethzero 33 | 34 | Il nostro ambiente di sviluppo integrato Mix e’ al momento in constante sviluppo e nonostante alcune caratteristiche siano gia’ presenti in questo tutorial ci concentreremo principalmente sullo sviluppo dei contratti, e la costruzione dei frontend utilizzando il nostro client di sviluppo Alethzero. Alethzero ha un compilatore gia’ integrato, una console javascript, e gli strumenti necessari per dare un’occhiata allo stato della blockchain. 35 | 36 | A meno che non sia espressamente specificato, questo tutorial deve essere eseguito su Alethzero utilizzando una chain privata e senza connettersi alla rete – inserire contratti nella rete di test dovrebbe essere riservato a quei contratti che volete condividere con altri. Quando caricate alethzero in questa modalita’ e’ possibile che altri accedano alla vostra chain fintanto che utilizzano lo stesso nome e usano la funzione ‘connect-to-peer’ per connettersi direttamente. 37 | -------------------------------------------------------------------------------- /Open-positions-&-Schemes.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Open Positions and Schemes 3 | category: 4 | --- 5 | 6 | ### Full-time Roles 7 | 8 | Ethereum has a number of full-time employee roles open. For the Berlin team (concentrating mostly around the C++-based implementation and development tools) you'll be based in Kreuzberg, Berlin in our central office/hub/café location, for the Amsterdam team (concentrating mostly around the Go-based implementation and the consumer software) you'll work remotely for now. Roles include security, optimisation, networking and helping make reality our advanced integrated blockchain development environment. We are presently particularly interested in expanding our team for the latter; if you have good knowledge of the Qt5 platform including QtQuick & QML, then please get in touch with `jobs@ethdev.com`. 9 | 10 | For more information on full time positions, see `TODO: Aeron`. 11 | 12 | ### Hub-Invitation Scheme 13 | 14 | If you have been working on an Ethereum/ÐΞV-related project, we would love to hear from you. In addition to helping wherever we can with fixes and advice, for promising non-profit, open-source projects where considerable effort has clearly been invested we would like to invite you to collaborate more closely at one of our holons/hubs. At present there are two operational hubs: 15 | 16 | - **ÐΞV Berlin** in Kreuzberg (Berlin), Germany; 17 | - **ÐΞV Amsterdam** near Museum Plein, Netherlands; 18 | - **Ethereum Suisse** in Zug (near Zurich), Switzerland. 19 | 20 | Such an invitation will include travel costs, a small stipend for food costs during the time and shared accommodation. You will have full access to the hub resources during your stay and be free to work and relax around other members of the local ÐΞV & Ethereum communities. 21 | 22 | Projects that are especially interesting to us are: 23 | - alternative implementations of the protocol in esoteric languages; 24 | - legacy-system (web back-end, but perhaps other frameworks/environments, too) integrations; 25 | - education and adoption tools; 26 | - Ðapps & contracts that do something novel; 27 | - Ðapps & contracts that do something well. 28 | 29 | If you believe you have such a project and would like to come visit us for a while, let us know at `visitus@ethdev.com`! 30 | 31 | ### Sponsoring Scheme 32 | 33 | Additionally, for interesting projects, we would like to extend financial support in the form of a small bursary. We consider all such projects, as with the Hub Invitation Scheme. Bursary amounts vary from the $1000s to the $10,000s, depending on the size, scope and outlook of the project. 34 | 35 | If you believe you have such a project let us know at `bursary@ethdev.com`, with a proposal for where you would like to take the project and estimates of any expenses that might be involved in taking it forward. 36 | 37 | ### FAQ 38 | 39 | Q. I want to make a client in language XYZ. I haven't started yet but was hoping you'd pay me a full developer's salary to do it. Can I have a job? 40 | 41 | A. No. Our resources do not extend so far. We wish you luck with your endeavour and if you get far would certainly invite you to our collaborative environment in the above scheme. 42 | 43 | Q. I have an idea for a contract/Ðapp/integration/... Could I get some money to fund its development? 44 | 45 | A. Ethereum/ÐΞV is not an accelerator, incubator or investment operation. We only wish to lend a hand (financial and otherwise) to those already engrossed in their project. As such our assistance schemes are open only to those whose already have an established project that is Ethereum-centric. -------------------------------------------------------------------------------- /Ethash-Design-Rationale.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Ethash Design Rationale 3 | category: 4 | --- 5 | 6 | Ethash is intended to satisfy the following goals: 7 | 8 | 1. **IO saturation**: The algorithm should consume nearly the entire available memory access bandwidth (this is a strategy toward achieving ASIC resistance, the argument being that commodity RAM, especially in GPUs, is much closer to the theoretical optimum than commodity computing capacity) 9 | 2. **GPU friendliness**: We try to make it as easy as possible to mine with GPUs. Targeting CPUs is almost certainly impossible, as potential specialization gains are too great, and there do exist criticisms of CPU-friendly algorithms that they are vulnerable to botnets, so we target GPUs as a compromise. 10 | 3. **Light client verifiability**: a light client should be able to verify a round of mining in under 0.01 seconds on a desktop in C, and under 0.1 seconds in Python or Javascript, with at most 1 MB of memory (but exponentially increasing) 11 | 4. **Light client slowdown**: the process of running the algorithm with a light client should be much slower than the process with a full client, to the point that the light client algorithm is not an economically viable route toward making a mining implementation, including via specialized hardware. 12 | 5. **Light client fast startup**: a light client should be able to become fully operational and able to verify blocks within 40 seconds in Javascript. 13 | 14 | ### FNV 15 | 16 | FNV was used to provide a data aggregation function which is (i) non-associative, and (ii) easy to compute. A commutative and associative alternative to FNV would be XOR. 17 | 18 | ### Parameters 19 | 20 | * A 16 MB cache was chosen because a smaller cache would allow for an ASIC to be produced far too easily using the light-evaluation method. The 16 MB cache still requires a very high bandwidth of cache reading, whereas a smaller cache could be much more easily optimized. A larger cache would lead to the algorithm being too hard to evaluate with a light client. 21 | * 256 parents per DAG item was chosen in order to ensure that time-memory tradeoffs can only be made at a worse-than-1:1 ratio. 22 | * The 1 GB DAG size was chosen in order to require a level of memory larger than the size at which most specialized memories and caches are built, but still small enough for ordinary computers to be able to mine with it. 23 | * The ~0.73x per year growth level was chosen to roughly be balanced with Moore's law increases at least initially (exponential growth has a risk of overshooting Moore's law, leading to a situation where mining requires very large amounts of memory and ordinary GPUs are no longer usable for mining). 24 | * 64 accesses was chosen because a larger number of accesses would lead to light verification taking too long, and a smaller number would mean that the bulk of the time consumption is the SHA3 at the end, not the memory reads, making the algorithm not so strongly IO-bound. 25 | * The epoch length cannot be infinite (ie. constant dataset) because then the algorithm could be optimized via ROM, and very long epoch lengths make it easier to create memory which is designed to be updated very infrequently and only read often. Excessively short epochs would increase barriers to entry as weak machines would need to spend much of their time on a fixed cost of updating the dataset. The epoch length can probably be reduced or increased substantially if design considerations require it. 26 | * The cache size and dataset size is prime in order to help mitigate the risk of cycles appearing in dataset item generation or mining. -------------------------------------------------------------------------------- /Morden.md: -------------------------------------------------------------------------------- 1 | Morden is the first Ethereum alternative testnet. It is expected to continue throughout the Frontier and Homestead era. 2 | 3 | ### Usage 4 | 5 | #### TurboEthereum (C++) 6 | 7 | This is supported natively on 0.9.93 and above. Pass the `--morden` argument in when starting any of the clients. e.g.: 8 | 9 | ``` 10 | > eth --morden 11 | ``` 12 | 13 | Or, for AlethZero 14 | 15 | ``` 16 | > alethzero --morden 17 | ``` 18 | 19 | #### PyEthApp (Python client) 20 | 21 | PyEthApp supports the morden network from v1.0.5 onwards: 22 | 23 | ``` 24 | > pyethapp --profile testnet run 25 | ``` 26 | 27 | #### geth (Go client) 28 | 29 | ``` 30 | > geth --testnet 31 | ``` 32 | 33 | #### Parity 34 | 35 | ``` 36 | > parity --chain=morden 37 | ``` 38 | 39 | 40 | ### Details 41 | 42 | - Network Identity: **2** 43 | - All parameters same as Frontier except: 44 | - genesis.json (given below); 45 | - Initial Account Nonce (`IAN`) is 2^20 (instead of 0 in all previous networks). 46 | - All accounts in the state trie have nonce >= `IAN`. 47 | - Whenever an account is inserted into the state trie it is initialised with nonce = `IAN`. 48 | - Genesis block hash: `0cd786a2425d16f152c658316c423e6ce1181e15c3295826d7c9904cba9ce303` 49 | - Genesis state root: `f3f4696bbf3b3b07775128eb7a3763279a394e382130f27c21e70233e04946a9` 50 | 51 | ### Seed Nodes 52 | - `enode://e58d5e26b3b630496ec640f2530f3e7fa8a8c7dfe79d9e9c4aac80e3730132b869c852d3125204ab35bb1b1951f6f2d40996c1034fd8c5a69b383ee337f02ddc@92.51.165.126:30303` 53 | 54 | ### Chain Specification (ECS) 55 | 56 | ```json 57 | { 58 | "name": "Morden", 59 | "engineName": "Ethash", 60 | "params": { 61 | "accountStartNonce": "0x0100000", 62 | "frontierCompatibilityModeLimit": "0x789b0", 63 | "maximumExtraDataSize": "0x20", 64 | "tieBreakingGas": false, 65 | "minGasLimit": "0x1388", 66 | "gasLimitBoundDivisor": "0x0400", 67 | "minimumDifficulty": "0x020000", 68 | "difficultyBoundDivisor": "0x0800", 69 | "durationLimit": "0x0d", 70 | "blockReward": "0x4563918244F40000", 71 | "registrar": "", 72 | "networkID" : "0x2" 73 | }, 74 | "genesis": { 75 | "nonce": "0x00006d6f7264656e", 76 | "difficulty": "0x20000", 77 | "mixHash": "0x00000000000000000000000000000000000000647572616c65787365646c6578", 78 | "author": "0x0000000000000000000000000000000000000000", 79 | "timestamp": "0x00", 80 | "parentHash": "0x0000000000000000000000000000000000000000000000000000000000000000", 81 | "extraData": "0x", 82 | "gasLimit": "0x2fefd8" 83 | }, 84 | "nodes": [ 85 | "enode://b1217cbaa440e35ed471157123fe468e19e8b5ad5bedb4b1fdbcbdab6fb2f5ed3e95dd9c24a22a79fdb2352204cea207df27d92bfd21bfd41545e8b16f637499@104.44.138.37:30303" 86 | ], 87 | "accounts": { 88 | "0000000000000000000000000000000000000001": { "balance": "1", "nonce": "1048576", "builtin": { "name": "ecrecover", "linear": { "base": 3000, "word": 0 } } }, 89 | "0000000000000000000000000000000000000002": { "balance": "1", "nonce": "1048576", "builtin": { "name": "sha256", "linear": { "base": 60, "word": 12 } } }, 90 | "0000000000000000000000000000000000000003": { "balance": "1", "nonce": "1048576", "builtin": { "name": "ripemd160", "linear": { "base": 600, "word": 120 } } }, 91 | "0000000000000000000000000000000000000004": { "balance": "1", "nonce": "1048576", "builtin": { "name": "identity", "linear": { "base": 15, "word": 3 } } }, 92 | "102e61f5d8f9bc71d0ad4a084df4e65e05ce0e1c": { "balance": "1606938044258990275541962092341162602522202993782792835301376", "nonce": "1048576" } 93 | } 94 | } 95 | ``` 96 | 97 | ### Getting Ether 98 | One way to get Ether is by using the [Ethereum wei faucet](http://faucet.ma.cx:3000/). Just type in your account address and enjoy some free ether. -------------------------------------------------------------------------------- /Solidity-standard-library.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Solidity Standard Library 3 | category: 4 | --- 5 | 6 | # Solidity standard library 7 | 8 | ### overview 9 | 10 | This is poc of solidity standard library. 11 | Probably all of the contracts, but `owned` && `mortal` will be removed soon. 12 | 13 | Here is solidity tutorial prepared by Eris team. [Click](https://eng.erisindustries.com/tutorials/2015/03/11/solidity-1/) 14 | 15 | 16 | ### contracts 17 | 18 | - [owned](#owned) 19 | - [mortal](#mortal) 20 | 21 | 22 | #### owned 23 | ``` 24 | contract owned{ 25 | function owned() { 26 | owner = msg.sender; 27 | } 28 | 29 | modifier onlyowner() { 30 | if(msg.sender==owner) _ 31 | } 32 | 33 | address owner; 34 | } 35 | ``` 36 | 37 | #### mortal 38 | 39 | ``` 40 | import "owned"; 41 | 42 | contract mortal is owned { 43 | function kill() { 44 | if (msg.sender == owner) suicide(owner); 45 | } 46 | } 47 | ``` 48 | 49 | ### poc_contracts 50 | - [Coin](#coin1) 51 | - [Config](#config) 52 | - [CoinReg](#coinreg) 53 | - [configUser](#configuser) 54 | - [Config](#config) 55 | - [named](#named) 56 | - [NameReg](#namereg) 57 | - [service](#service) 58 | - [std](#std) 59 | 60 | #### coin 61 | ``` 62 | import "CoinReg"; 63 | import "Config"; 64 | import "configUser"; 65 | 66 | contract coin is configUser { 67 | function coin(string3 name, uint denom) { 68 | CoinReg(Config(configAddr()).lookup(3)).register(name, denom); 69 | } 70 | } 71 | ``` 72 | 73 | #### Coin 74 | ``` 75 | contract Coin { 76 | function isApprovedFor(address _target,address _proxy) constant returns(bool _r) {} 77 | function isApproved(address _proxy)constant returns(bool _r){} 78 | function sendCoinFrom(address _from,uint256 _val,address _to){} 79 | function coinBalanceOf(address _a)constant returns(uint256 _r){} 80 | function sendCoin(uint256 _val,address _to){} 81 | function coinBalance()constant returns(uint256 _r){} 82 | function approve(address _a){} 83 | } 84 | ``` 85 | 86 | #### CoinReg 87 | ``` 88 | contract CoinReg { 89 | function count()constant returns(uint256 r){} 90 | function info(uint256 i)constant returns(address addr,string3 name,uint256 denom){} 91 | function register(string3 name,uint256 denom){}function unregister(){} 92 | } 93 | ``` 94 | 95 | #### configUser 96 | ``` 97 | contract configUser { 98 | function configAddr()constant returns(address a){ 99 | return 0xc6d9d2cd449a754c494264e1809c50e34d64562b; 100 | } 101 | } 102 | ``` 103 | 104 | #### Config 105 | ``` 106 | contract Config { 107 | function lookup(uint256 service)constant returns(address a){} 108 | function kill(){}function unregister(uint256 id){} 109 | function register(uint256 id,address service){} 110 | } 111 | ``` 112 | 113 | #### named 114 | ``` 115 | import "Config"; 116 | import "NameReg"; 117 | import "configUser"; 118 | 119 | contract named is configUser { 120 | function named(string32 name) { 121 | NameReg(Config(configAddr()).lookup(1)).register(name); 122 | } 123 | } 124 | ``` 125 | 126 | #### NameReg 127 | ``` 128 | contract NameReg { 129 | function register(string32 name){} 130 | function addressOf(string32 name)constant returns(address addr){} 131 | function unregister(){}function nameOf(address addr)constant returns(string32 name){} 132 | } 133 | ``` 134 | 135 | 136 | #### service 137 | ``` 138 | import "Config"; 139 | import "configUser"; 140 | 141 | contract service is configUser { 142 | function service(uint _n){ 143 | Config(configAddr()).register(_n, this); 144 | } 145 | } 146 | ``` 147 | 148 | #### std 149 | ``` 150 | import "owned"; 151 | import "mortal"; 152 | import "Config"; 153 | import "configUser"; 154 | import "NameReg"; 155 | import "named"; 156 | ``` -------------------------------------------------------------------------------- /_Sidebar.md: -------------------------------------------------------------------------------- 1 | ### Basics 2 | - [Home](./Home) 3 | - [Ethereum Whitepaper](./White-Paper) 4 | - [Ethereum Yellow Paper](http://gavwood.com/Paper.pdf) 5 | - [FAQ](./FAQ) 6 | 7 | ### Ðapp Development 8 | - [Ðapp Developer Resources](./Dapp-Developer-Resources) 9 | - [JavaScript API](./JavaScript-API) 10 | - [JSON RPC API](./JSON-RPC) 11 | - [Solidity](https://ethereum.github.io/solidity/docs/home/) 12 | - [Solidity Features](./Solidity-Features) 13 | - [Useful Ðapp Patterns](./Useful-Ðapp-Patterns) 14 | - [Standardized Contract APIs](./Standardized_Contract_APIs) 15 | - [Ðapp using Meteor](./Dapp-using-Meteor) 16 | - [Ethereum development tutorial](./Ethereum-Development-Tutorial) 17 | - [Mix Tutorial](./Mix:-The-DApp-IDE) 18 | - [Mix Features](./Mix-Features) 19 | - [Serpent](./Serpent) 20 | - [LLL](https://github.com/ethereumproject/cpp-ethereum/wiki/LLL) 21 | - [Mutan](https://github.com/obscuren/mutan) 22 | 23 | ### Infrastructure 24 | - [Morden Testnet](https://github.com/ethereum/wiki/wiki/Morden) 25 | - [Chain Spec Format](https://github.com/ethereum/wiki/wiki/Ethereum-Chain-Spec-Format) 26 | - [Inter-exchange Client Address Protocol](https://github.com/ethereum/wiki/wiki/ICAP:-Inter-exchange-Client-Address-Protocol) 27 | - [URL Hint Protocol](https://github.com/ethereum/wiki/wiki/URL-Hint-Protocol) 28 | - [NatSpec Determination](https://github.com/ethereum/wiki/wiki/NatSpec-Determination) 29 | - [Network Status](https://github.com/ethereum/wiki/wiki/Network-Status) 30 | - [Raspberry Pi](https://github.com/ethereum/wiki/wiki/Raspberry-Pi-instructions) 31 | - [Exchange Integration](https://github.com/ethereum/wiki/wiki/Exchange-Integration) 32 | - [Mining](https://github.com/ethereum/wiki/wiki/Mining) 33 | - [Licensing](https://github.com/ethereum/wiki/wiki/Licensing) 34 | - [Consortium Chain Development](https://github.com/ethereum/wiki/wiki/Consortium-Chain-Development) 35 | 36 | ### ÐΞV Technologies 37 | - [RLP Encoding](./RLP) 38 | - [RLPx Node Discovery Protocol](./Node-discovery-protocol-(RLPx)) 39 | - [ÐΞVp2p Wire Protocol](./%C3%90%CE%9EVp2p-Wire-Protocol) 40 | - [ÐΞVp2p Whitepaper](./libp2p-Whitepaper) (WiP) 41 | - [Web3 Secret Storage](./Web3-Secret-Storage-Definition) 42 | 43 | ### Ethereum Technologies 44 | - [Patricia Tree](./Patricia-Tree) 45 | - [Wire protocol](./Ethereum-Wire-Protocol) 46 | - [Light client protocol](./Light-client-protocol) 47 | - [Subtleties](./Subtleties) 48 | - [Solidity, Docs & ABI](./Solidity,-Docs-and-ABI) 49 | - [NatSpec Format](./Ethereum-Natural-Specification-Format) 50 | - [Contract ABI](./Ethereum-Contract-ABI) 51 | - [Bad Block Reporting](./Bad-Block-Reporting) 52 | - [Bad Chain Canary](./Bad-Chain-Canary) 53 | - [Extra Data](./Extra-Data) 54 | - [Brain Wallet](./Brain-Wallet) 55 | 56 | ### Ethash/Dashimoto 57 | - [Ethash](./Ethash) 58 | - [Ethash C API](./Ethash-C-API) 59 | - [Ethash DAG](./Ethash-DAG) 60 | 61 | ### Infrastructure Development 62 | - [Morden](./Morden) 63 | - [Inter-exchange Client Address Protocol](./ICAP:-Inter-exchange-Client-Address-Protocol) 64 | - [URL Hint Protocol](./URL-Hint-Protocol) 65 | - [NatSpec Determination](./NatSpec-Determination) 66 | - [Exchange Integration](./Exchange-Integration) 67 | - [Mining](./Mining) 68 | - [Licensing](./Licensing) 69 | - [Network Status](./Network-Status) 70 | - [Raspberry Pi](./Raspberry-Pi-instructions) 71 | 72 | ### Ethereum Classic Clients 73 | - [Geth (Go)](https://github.com/ethereumproject/go-ethereum) 74 | - [Parity (Rust)](https://github.com/paritytech/parity) 75 | - [pyeth (Python)](./Pyeth) 76 | 77 | ### Concerning Whisper 78 | - [Whisper Proposal](./Whisper) 79 | - [Whisper Overview](./Whisper-Overview) 80 | - [PoC-1 Wire protocol](./Whisper-Wire-Protocol) 81 | - [PoC-2 Wire protocol](./Whisper-PoC-2-Wire-Protocol) 82 | - [PoC-2 Whitepaper](./Whisper-PoC-2-Protocol-Spec) 83 | 84 | ### Misc 85 | - [Hard Problems of Cryptocurrency](./Problems) 86 | - [Chain Fibers](./Chain-Fibers-Redux) 87 | - [Glossary](./Glossary) 88 | -------------------------------------------------------------------------------- /Proposal:-Transaction-Proxy-Hooks.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Transaction Proxy Hooks Proposal 3 | category: 4 | --- 5 | 6 | ## Requirements 7 | 8 | Need an abstraction mechanism to allow ÐApps like the Wallet provide their services in an integrated manner without compromising the neutrality of the browser or placing undue burden on third-party ÐApp developers to support them. 9 | 10 | ## Basic Design 11 | 12 | The ethereum.js interface may be utilised to allow the ÐApp client to register itself as the transaction handler for each of a number of accounts; in doing so it will provide an additional callback. 13 | 14 | This is done through one addition to the ethereum.js `web3.eth` object, `registerProxyTransactor`: 15 | 16 | ``` 17 | var addresses = []; 18 | // TODO: populate addresses 19 | 20 | function f(tx) { 21 | // tx includes tx.from, tx.to, tx.data, tx.value, tx.gasPrice, tx.gas 22 | // and is *exactly* the same as what was passed to eth.transact, but probably not in this 23 | // JS environment. 24 | // tx.from is guaranteed to be an element of addresses. 25 | // TODO: do something 26 | } 27 | 28 | web3.eth.registerProxyTransactor(addresses, f); 29 | ``` 30 | 31 | That's the entire JS API. 32 | 33 | In terms of JSON-RPC, there must be an alteration to `eth_accounts`: rather than just including the accounts that we have the secret key for (and that the user has accepted are valid for this dapp to use and know about), all accounts passed as the first argument to `registerProxyTransactor` should also be contained (with the same safeguards as per user acceptance). 34 | 35 | There are also two additional calls in the JSON-RPC; one for polling the status of whether any transactions are waiting to be signed by our callback that we registered as the second argument of `registerProxyTransactor`, and one for letting the core know that our ethereum.js object is capable of proxying transactions sent from the addresses passed as the first argument of `registerProxyTransactor`. 36 | 37 | The first is `eth_registerAddressHandler`; it takes one argument which is an array of addresses and returns an integer identifier. Any otherwise unsignable transactions whose from address is included in this array should be, at some time later, returned to this session as a result of polling the RPC function `eth_checkProxyTransactions`. 38 | 39 | `eth_checkProxyTransactions` takes one argument - the previous integer identifier and returns an array of transactions, each of the form that are passed to `web3.eth.transact`. 40 | 41 | ### Core 42 | 43 | Cores must maintain queues of proxy transactions together with sets of addresses, one each per ethereum.js `web3.eth` object (identified through the integer returned to `eth_registerAddressHandler` and provided by `eth_checkProxyTransactions`). These transactions are to be returned to the session via `eth_checkProxyTransactions`. They are to be filled whenever an `eth_transact` is called (from any session) with a `from` address that is contained in the corresponding set of proxyable addresses. 44 | 45 | 46 | ### Notes 47 | 48 | If it's called twice, all previous state associated with it is replaced. If two ethereum.js `web3.eth` objects both try to handle the same address, the first one wins and the second silently fails. 49 | 50 | NatSpec messages should be shown for all transactions, ideally only a single ultimate user action required for any given high-level transaction. E.g.: 51 | 52 | - Send 56 ether to `Dave - 0x56789123` from account `Gav's Bank Account - 0x12345678`. 53 | - Wallet ÐApp handling account `Gav's Bank Account - 0x12345678` requests authorisation to conduct the above through: Message from `Gav - 0x34343455` to `Gav's Bank Account - 0x12345678` to: Send 56 ether to `Dave - 0x56789123`. 54 | 55 | The first NatSpec line just corresponds to the first bare and impossible-to-sign transaction from a contract. The second is the actual transaction that will be signed, stating that Gav (the account for which we have a secret key), would sign a transaction instructing the wallet to send the funds. -------------------------------------------------------------------------------- /pages/rlp/[romanian]-rlp.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: RLP 3 | category: 4 | --- 5 | 6 | Scopul RLP este acela de a coda matrici grupate arbitrar de date binare, si RLP este principala metoda folosita pentru a serializa obiecte in Ethereum. Singurul scop al RLP este acela de a coda structuri, codarea unor tipuri specifice de date atomice (strings, ints, float) sunt lasate pentru alte protocoale de ordin superior; in Ethereum standardul este reprezentarea numerelor intregi in forma endiana binara. Daca cineva doreste sa utilizeze RLP pentru a coda un dictionar, cele doua forme canonice sugerate vor folosi `[[k1,v1],[k2,v2]...]` keys in ordine lexicografica sau vor folosi codarea Patricia Tree, ca la Ethereum. 7 | 8 | ###Definitie 9 | 10 | Functia de encodare RLP preia un element. Un element este definit dupa cum urmeaza: 11 | - Un sir (ex. o matrice octet) este un element 12 | - O lista de elemente este un element 13 | De exemplu, un sir gol este un element, cum este sirul care conține cuvantul "pisica", o lista ce contine orice numar de siruri, ca si structuri de date mai complexe precum` ["pisica",["catelus","vaca"],"cal",[[]],"porc",[""],"oaie"]`. Retineti ca in contextul acestui articol, “sir” va fi folosit ca un sinonim pentru “un anumit numar de bytes de date binare”, nu sunt folosite codari speciale si nu implica resurse legate de continutul sirurilor. 14 | Codarea RLP este definita dupa cum urmeaza: 15 | -Pentru un singur byte a carui valoare se incadreaza in `[0x00, 0x7f]` , acel byte este propria sa codare RLP. 16 | -Altfel, daca un sir are o lungime de 0-55 bytes, codarea RLP consta intr-un singur byte cu o valoare de 0x80 plus lungimea sirului, urmata de sir. Astfel, primul byte se incadreaza in intervalul `[0x80, 0xb7]`. 17 | -Daca un sir este mai lung de 55 bytes, codarea RLP consta intr-un singur byte cu valoarea 0xb7 plus lungimea lungimii sirului in forma binara, urmata de lungimea sirului,urmata de sir. De exemplu, un sir de o lungime 1024 ar fi codat \xb9\x04\x00 , urmat de sir. Intervalul in care se incadreaza primul byte este, deci, `[0xb8, 0xbf]`. 18 | 19 | - Daca sarcina utila a unei liste (payload) (ex. Suma lungimilor elementelor sale) are o lungime de 0-55 bytes, codarea RLP consta intr-un singur byte cu valoarea de 0xc0 plus lungimea listei urmata de concatenarea/juxtapunerea codarii RLP a elementelor. Intervalul in care se incadreaza primul byte este `[0xc0, 0xf7]`. 20 | - Daca sarcina utila a unei liste (payload) este mai mare de 55 bytes, codarea RLP consta intr-un singur byte cu valoarea de 0xf7 plus lungimea lungimii listei in forma binara, urmata de lungimea listei , urmata de concatenarea/juxtapunerea codarii RLP a elementelor. Intervalul in care este plasat primul octet este `[0xf8, 0xff]`. 21 | 22 | Codul, arata astfel: 23 | ```python 24 | def rlp_encode(input): 25 | if isinstance(input,str): 26 | if len(input) == 1 and chr(input) < 128: return input 27 | else: return encode_length(len(input),128) + input 28 | elif isinstance(input,list): 29 | output = encode_length(len(input),192) 30 | for item in input: output += rlp_encode(item) 31 | return output 32 | 33 | def encode_length(L,offset): 34 | if L < 56: 35 | return chr(L + offset) 36 | elif L < 256**8: 37 | BL = to_binary(L) 38 | return chr(len(BL) + offset + 55) + BL 39 | else: 40 | raise Exception("input too long") 41 | 42 | def to_binary(x): 43 | return '' if x == 0 else to_binary(int(x / 256)) + chr(x % 256) 44 | ``` 45 | 46 | ###Exemple: 47 | 48 | Sirul “dog”= `[ 0x83, 'd', 'o', 'g' ]` 49 | 50 | Lista [ "cat", "dog" ] = `[ 0xc8, 0x83, 'c', 'a', 't', 0x83, 'd', 'o', 'g' ]` 51 | 52 | Sirul gol ('null') = `[ 0x80 ]` 53 | 54 | Lista goala =`[ 0xc0 ]` 55 | 56 | Numarul intreg 15= `[ 0x0f ]` 57 | 58 | Numarul intreg 1024 =`[ 0x82, 0x04, 0x00 ]` 59 | 60 | Reprezentarea teoretica a setului de 2 , [ [], [[]], [ [], [[]] ] ] = `[ 0xc7, 0xc0, 0xc1, 0xc0, 0xc3, 0xc0, 0xc1, 0xc0 ]` 61 | 62 | Sirul "Lorem ipsum dolor sit amet, consectetur adipisicing elit" = `[ 0xb8, 0x38, 'L', 'o', 'r', 'e', 'm', ' ', ... , 'e', 'l', 'i', 't' ]` 63 | -------------------------------------------------------------------------------- /Proposal:-Reversion-Notification.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Reversion Notification Proposal 3 | category: 4 | --- 5 | 6 | ## **JSONRPC** changes: 7 | 8 | `eth_getFilterChanges`, `eth_getFilterLogs` both return additional fields: "type" and "polarity" 9 | 10 | - `type`: `STRING` - `pending` when the log is pending. `mined` if log is already mined. 11 | - `polarity`:`BOOL` - either `true` (the transaction pertaining to this log was mined or arrived as pending compared to the previous notification/notified block) or `false` (the transaction pertaining to this log was reverted or was deleted compared to the previous notification/notified block). 12 | 13 | ```diff 14 | // Result 15 | { 16 | "id":1, 17 | "jsonrpc":"2.0", 18 | "result": [{ 19 | "logIndex": "0x1", // 1 20 | "blockNumber":"0x1b4" // 436 21 | "blockHash": "0x8216c5785ac562ff41e2dcfdf5785ac562ff41e2dcfdf829c5a142f1fccd7d", 22 | "transactionHash": "0xdf829c5a142f1fccd7d8216c5785ac562ff41e2dcfdf5785ac562ff41e2dcf", 23 | "transactionIndex": "0x0", // 0 24 | "address": "0x16c5785ac562ff41e2dcfdf829c5a142f1fccd7d", 25 | "data":"0x0000000000000000000000000000000000000000000000000000000000000000", 26 | + "type":"mined", 27 | + "polarity": true, 28 | "topics": ["0x59ebeb90bc63057b6515673c3ecf9438e5058bca0f92585014eced636878c9a5"] 29 | },{ 30 | ... 31 | }] 32 | } 33 | ``` 34 | 35 | - logs order 36 | 37 | logs should be returned in order, from earliest to latest. 38 | 39 | In case of fork, the order should be following: 40 | 41 | ``` 42 | // 43 | // ......1 - 2 - 3a - 4a 44 | // ...............\- 3b - 4b - 5b 45 | // 46 | // getLogs({fromBlock: 4a, toBlock: 5b}) should return 47 | // 4a, 3a, 3b, 4b, 5b 48 | // 49 | ``` 50 | 51 | 52 | 53 | ## **JSONRPC** new methods: 54 | 55 | - `eth_newFilterEx` (new version of `eth_newFilter`) 56 | - `eth_getLogsEx` (new version of `eth_getLogs`) 57 | 58 | They expect 'fromBlock', 'toBlock' to be block hash instead of block number. 59 | 60 | ```diff 61 | params: [{ 62 | - "fromBlock": "0x1", 63 | + "fromBlock": "0x599438826541d3e8c29c167fa15b491d91b65e422f8b8a3da69eaa9a43c832e1", 64 | - "toBlock": "0x2", 65 | + "toBlock": "0x599438826541d3e8c29c167fa15b491d91b65e422f8b8a3da69eaa9a43c832e1", 66 | "address": "0x8888f1f195afa192cfee860698584c030f4c9db1", 67 | "topics": ["0x000000000000000000000000a94f5374fce5edbc8e2a8697c15331677e6ebf0b"] 68 | }] 69 | ``` 70 | 71 | - `eth_getFilterChangesEx` (new version of `eth_getFilterChanges`) 72 | - `eth_getFilterLogsEx` (new version of `eth_getFilterLogs`) 73 | 74 | `eth_getFilterChangesEx` && `eth_getFilterLogsEx` have the same input params as `eth_getFilterChanges` && `eth_getFilterLogs`, but different format of returned objects. 75 | 76 | ``` 77 | // Result 78 | { 79 | "id":1, 80 | "jsonrpc":"2.0", 81 | "result": [{ 82 | "blockNumber":"0x1b4" // 436 83 | "blockHash": "0x8216c5785ac562ff41e2dcfdf5785ac562ff41e2dcfdf829c5a142f1fccd7d", 84 | "type": "pending", 85 | "polarity": true, 86 | "logs": [{ 87 | "logIndex": "0x1", // 1 88 | "transactionHash": "0xdf829c5a142f1fccd7d8216c5785ac562ff41e2dcfdf5785ac562ff41e2dcf", 89 | "transactionIndex": "0x0", // 0 90 | "address": "0x16c5785ac562ff41e2dcfdf829c5a142f1fccd7d", 91 | "data":"0x0000000000000000000000000000000000000000000000000000000000000000", 92 | "topics": ["0x59ebeb90bc63057b6515673c3ecf9438e5058bca0f92585014eced636878c9a5"] 93 | },{ 94 | ... 95 | }], 96 | },{ 97 | ... 98 | }] 99 | } 100 | ``` 101 | 102 | 103 | ## Comments: 104 | 105 | **Fabian**: I like it but i would change three things: 106 | 107 | 1. `polarity: true` -> `invalidated: true` or `invalid: true` 108 | 2. get rid of the old filter and add `eth_newFilterEx` as `eth_newLogFilter`, to make it fit the other filter type names (`eth_newBlockFilter`, `etH_newPendingTransactionFilter`) 109 | 3. Don't return logs grouped by blocks, as i don't see an advantage besides that it is harder to parse. (Logs don't really care in which block they came, though we need to add the `blockX` properties for reference) -------------------------------------------------------------------------------- /libp2p-Whitepaper.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Lib P2P Whitepaper 3 | category: 4 | --- 5 | 6 | **NOTE:** *This is a work-in-progress* 7 | 8 | For Ethereum to succeed, and for the ultimate goals of Ethereum to be achieved, Ethereum needs to employ a number of secure decentralised data systems. The generalised Turing-complete, extensible-state blockchain is one component in this, but for it to be leveraged to its full potential for building decentralised applications (ÐApps), a suite of additional data systems are necessary. Each decentralised-datasystem solves specific needs; in general it is difficult to predict what data systems will ultimately be required since the decentralised paradigm is not immediately comparable, like-for-like with traditional centralised architected systems. 9 | 10 | Three types of data systems in particular are required for many current massively multi-user applications (MMAs, aka generally Web-based applications but also mobile phone apps and e.g. MMORPGs). In addition to a transactional database ("Ethereum"), a publication and download system would be required in addition to a generalised low-level "bulletin-board" system for posting messages. 11 | 12 | We can, however, imagine many more such types of decentralised communications systems in the future including, e.g., those for identity-based RTC. Each of these components have a number of shared prerequisites, such as peer-discovery and recording; network well-formedness; transport-level buffering, scheduling and framing; and authentication and security. Any computer scientist worth their salt would instantly scream out "abstraction opportunity!". 13 | 14 | ### What it is 15 | 16 | libp2p (aka ÐΞVp2p) aims to provide a lightweight abstraction layer that provides these low-level algorithms, protocols and services in a transparent framework without predetermining the eventual transmission-use-cases of the protocols. 17 | 18 | Its specific aims are to provide a language-agnostic API and specification which is: 19 | - *Universal:* Pairwise addressing (ala Telehash), broadcast (ala Bitcoin), groupwise (some DHT designs & filesharing) are all reasonable. There may be others. It should provide only the network structure, not dictate usage over it. 20 | - *Ubiquitous:* The same peer-set/-network should be able to be used for all protocols. 21 | - *Secure:* Encryption between physical peers is a given. Peer introduction can provide a good level of defence against systematic MitM attacks. 22 | - *Efficient:* Framing and prioritisation to guarantee QoS over each protocol. Multiplexing allows access to limited resources to be easily controlled between p2p protocols. Kademlia-style network well-formedness guarantees a low maximum hope distance to any peer in the network and its group. 23 | - *Simple:* A minimal, developer-driven API gives source-level future-proofing. 24 | 25 | Ultimately, additional secondary features will also be explored: 26 | - *DPI security:* Framing and bandwidth control can be used to control traffic shape. 27 | - *Transport-layer Agnostic:* TCP/IP v4 and v6 are provided with initial protocol specifications. Others should be able to be added on at later dates without altering the API. Mesh networking devices could even ultimately implement this natively. 28 | 29 | ### Basic Design 30 | 31 | - Peers can each be identified by a node-ID. 32 | - Provides ability *only* to communicate with peers. 33 | - Everything happens in typed, ordered datagrams. 34 | - Any number of datagram types can be registered - these are automatically negotiated at the handshake. 35 | - Peers can be requested via a libp2p physical endpoint. 36 | - Peers can be rated per-protocol using a local metric. 37 | - Peer set is dynamic and "steered" by libp2p internally, going from ratings. 38 | - First packets are either DH key exchange or, if node known from peer introduction, PKI-encrypted session key, or if node known from previous session, new session key encrypted by old. Retry can be made after failed negotiation using prior knowledge, with the corresponding removal of any trust. 39 | - Peer-set is made up from multiple sub-protocol slots. 40 | - Each slot is given over to maximise rating for that particular sub-protocol. 41 | 42 | There is no preordained inter-node message routing system (this is left to a higher-level), and no preordained high-level identity system (again, higher level). 43 | -------------------------------------------------------------------------------- /Network-Status.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: NatSpec Status 3 | category: 4 | --- 5 | 6 | # Network Status Monitoring 7 | 8 | The [Ethereum (centralised) network status monitor](https://ethstats.net) (known sometimes as "eth-netstats") is a web-based application to monitor the health of the testnet/mainnet through a group of nodes. 9 | 10 | ## Listing 11 | 12 | To list your node, you must install the client-side information relay, a node module. Instructions given here work on Ubuntu (Mac OS X follow same instructions, but sudo may be unnecessary). Other platforms vary (please make sure that nodejs-legacy is also installed, otherwise some modules might fail). 13 | 14 | Clone the git repo, then install pm2: 15 | 16 | ``` 17 | git clone https://github.com/cubedro/eth-net-intelligence-api 18 | cd eth-net-intelligence-api 19 | npm install 20 | sudo npm install -g pm2 21 | ``` 22 | 23 | Then edit the `app.json` file in it to configure for your node: 24 | 25 | - alter the value to the right of `LISTENING_PORT` to the ethereum listening port (default: 30303) 26 | - alter the value to the right of `INSTANCE_NAME` to whatever you wish to name your node; 27 | - alter the value to the right of `CONTACT_DETAILS` if you wish to share your contact details 28 | - alter the value to the right of `RPC_PORT` to the rpc port for your node (by default 8545 for both cpp and go); 29 | - and alter the value to the right of `WS_SECRET` to the secret (you'll have to get this off [the official skype channel](http://tinyurl.com/ofndjbo)). 30 | 31 | ethereum (eth or geth) must be running with rpc enabled. 32 | ``` 33 | geth --rpc 34 | ``` 35 | the default port (if one is not specified) for rpc under geth is 8545 36 | 37 | Finally run the process with: 38 | 39 | ``` 40 | pm2 start app.json 41 | ``` 42 | 43 | Several commands are available: 44 | 45 | - `pm2 list` to display the process status; 46 | - `pm2 logs` to display logs; 47 | - `pm2 gracefulReload node-app` for a soft reload; 48 | - `pm2 stop node-app` to stop the app; 49 | - `pm2 kill` to kill the daemon. 50 | 51 | ### Updating 52 | In order to update you have to do the following: 53 | - `git pull` to pull the latest version 54 | - `sudo npm update` to update the dependencies 55 | - `pm2 gracefulReload node-app` to reload the client 56 | 57 | 58 | *** 59 | 60 | ## Auto-installation on a fresh Ubuntu install 61 | Fetch and run the build shell. This will install everything you need: latest ethereum - CLI from develop branch (you can choose between eth or geth), node.js, npm & pm2. 62 | 63 | ```bash 64 | bash <(curl https://raw.githubusercontent.com/cubedro/eth-net-intelligence-api/master/bin/build.sh) 65 | ``` 66 | 67 | ### Configuration 68 | Configure the app modifying [app.json](https://github.com/cubedro/eth-net-intelligence-api/blob/master/app.json.example). Note that you have to modify the backup `app.json` (to allow you to set your env vars without being rewritten when updating). 69 | 70 | ```js 71 | "env": 72 | { 73 | "NODE_ENV" : "production", // tell the client we're in production environment 74 | "RPC_HOST" : "localhost", // eth JSON-RPC host the default is 8545 75 | "RPC_PORT" : "8545", // eth JSON-RPC port 76 | "LISTENING_PORT" : "30303", // eth listening port (only used for display) 77 | "INSTANCE_NAME" : "", // whatever you wish to name your node 78 | "CONTACT_DETAILS" : "", // add your contact details here if you wish (email/skype) 79 | "WS_SERVER" : "wss://rpc.ethstats.net", // path to eth-netstats WebSockets api server 80 | "WS_SECRET" : "", // WebSockets api server secret used for login 81 | } 82 | ``` 83 | 84 | ### Run 85 | 86 | Run it using pm2: 87 | 88 | ```bash 89 | cd ~/bin 90 | pm2 start processes.json 91 | ``` 92 | 93 | ethereum (eth or geth) must be running with rpc enabled. 94 | 95 | ``` 96 | geth --rpc 97 | ``` 98 | the default port (if one is not specified) for rpc under geth is 8545 99 | 100 | ### Updating 101 | To update the API client use the following command: 102 | 103 | ```bash 104 | ~/bin/www/bin/update.sh 105 | ``` 106 | 107 | It will stop the current netstats client processes, automatically detect your ethereum implementation and version, update it to the latest develop build, update netstats client and reload the processes. -------------------------------------------------------------------------------- /pages/rlp/[english]-rlp.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: RLP 3 | category: 4 | --- 5 | 6 | The purpose of RLP (Recursive Length Prefix) is to encode arbitrarily nested arrays of binary data, and RLP is the main encoding method used to serialize objects in Ethereum. The only purpose of RLP is to encode structure; encoding specific atomic data types (eg. strings, ints, floats) is left up to higher-order protocols; in Ethereum integers must be represented in big endian binary form with no leading zeroes (thus making the integer value zero be equivalent to the empty byte array). 7 | 8 | If one wishes to use RLP to encode a dictionary, the two suggested canonical forms are to either use `[[k1,v1],[k2,v2]...]` with keys in lexicographic order or to use the higher-level [Patricia Tree](./Patricia-Tree) encoding as Ethereum does. 9 | 10 | ### Definition 11 | 12 | The RLP encoding function takes in an item. An item is defined as follows: 13 | 14 | * A string (ie. byte array) is an item 15 | * A list of items is an item 16 | 17 | For example, an empty string is an item, as is the string containing the word "cat", a list containing any number of strings, as well as more complex data structures like `["cat",["puppy","cow"],"horse",[[]],"pig",[""],"sheep"]`. Note that in the context of the rest of this article, "string" will be used as a synonym for "a certain number of bytes of binary data"; no special encodings are used and no knowledge about the content of the strings is implied. 18 | 19 | RLP encoding is defined as follows: 20 | 21 | * For a single byte whose value is in the `[0x00, 0x7f]` range, that byte is its own RLP encoding. 22 | * Otherwise, if a string is 0-55 bytes long, the RLP encoding consists of a single byte with value **0x80** plus the length of the string followed by the string. The range of the first byte is thus `[0x80, 0xb7]`. 23 | * If a string is more than 55 bytes long, the RLP encoding consists of a single byte with value **0xb7** plus the length in bytes of the length of the string in binary form, followed by the length of the string, followed by the string. For example, a length-1024 string would be encoded as `\xb9\x04\x00` followed by the string. The range of the first byte is thus `[0xb8, 0xbf]`. 24 | * If the total payload of a list (i.e. the combined length of all its items) is 0-55 bytes long, the RLP encoding consists of a single byte with value **0xc0** plus the length of the list followed by the concatenation of the RLP encodings of the items. The range of the first byte is thus `[0xc0, 0xf7]`. 25 | * If the total payload of a list is more than 55 bytes long, the RLP encoding consists of a single byte with value **0xf7** plus the length in bytes of the length of the payload in binary form, followed by the length of the payload, followed by the concatenation of the RLP encodings of the items. The range of the first byte is thus `[0xf8, 0xff]`. 26 | 27 | In code, this is: 28 | 29 | ```python 30 | def rlp_encode(input): 31 | if isinstance(input,str): 32 | if len(input) == 1 and ord(input) < 128: return input 33 | else: return encode_length(len(input),128) + input 34 | elif isinstance(input,list): 35 | output = '' 36 | for item in input: output += rlp_encode(item) 37 | return encode_length(len(output),192) + output 38 | 39 | def encode_length(L,offset): 40 | if L < 56: 41 | return chr(L + offset) 42 | elif L < 256**8: 43 | BL = to_binary(L) 44 | return chr(len(BL) + offset + 55) + BL 45 | else: 46 | raise Exception("input too long") 47 | 48 | def to_binary(x): 49 | return '' if x == 0 else to_binary(int(x / 256)) + chr(x % 256) 50 | ``` 51 | 52 | ### Examples 53 | 54 | The string "dog" = [ 0x83, 'd', 'o', 'g' ] 55 | 56 | The list [ "cat", "dog" ] = `[ 0xc8, 0x83, 'c', 'a', 't', 0x83, 'd', 'o', 'g' ]` 57 | 58 | The empty string ('null') = `[ 0x80 ]` 59 | 60 | The empty list = `[ 0xc0 ]` 61 | 62 | The encoded integer 15 ('\x0f') = `[ 0x0f ]` 63 | 64 | The encoded integer 1024 ('\x04\x00') = `[ 0x82, 0x04, 0x00 ]` 65 | 66 | The [set theoretical representation](http://en.wikipedia.org/wiki/Set-theoretic_definition_of_natural_numbers) of three, `[ [], [[]], [ [], [[]] ] ] = [ 0xc7, 0xc0, 0xc1, 0xc0, 0xc3, 0xc0, 0xc1, 0xc0 ]` 67 | 68 | The string "Lorem ipsum dolor sit amet, consectetur adipisicing elit" = `[ 0xb8, 0x38, 'L', 'o', 'r', 'e', 'm', ' ', ... , 'e', 'l', 'i', 't' ]` 69 | -------------------------------------------------------------------------------- /pages/rlp/[german]-rlp.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: RLP 3 | category: 4 | --- 5 | 6 | Der Zweck von RLP ist es, beliebig verschachtelte Arrays von binären Daten zu kodieren. RLP wird als Hauptcodierungsverfahren verwendet, um Objekte in Ethereum in serieller Reihenfolge zu kodieren. Das heisst RLP kodiert Strukturen, spezielle Datentypen wie [Strings] (http://de.wikipedia.org/wiki/Zeichenkette), [Integers] (http://de.wikipedia.org/wiki/Integer_%28Datentyp%29) und [Floats] (http://de.wikipedia.org/wiki/Gleitkommazahl), bis hin zu höheren Protokollebenen. Integer werden in Ethereum standardmäßig im [Big Endian] (http://de.wikipedia.org/wiki/Byte-Reihenfolge) Binärfomat verarbeitet. 7 | Wenn man RLP z.B. zum Kodieren eines Wörterbuchs verwendet, sind die beiden vorgeschalgenen Standardformen entweder `[[k1, v1], [k2, v2] ...]` mit Schlüsselwörtern in lexikographische Ordnung oder besser die Kodierung des [Patricia Baums] (./Patricia-Tree) (wie es Ethereum tut). 8 | 9 | ### Definition 10 | Die RLP-Koding erfolgt in einem Element. Ein Element wird wie folgt definiert: 11 | 12 | * Ein String (z.B. eine Byte Array) ist ein Element 13 | * Eine Liste von Elementen ist ein Elemet 14 | 15 | Elemente können z.B. sein: 16 | - ein leerer String 17 | - ein String mit dem Wort "cat" 18 | - eine Liste von beliebig vielen anderen Zeichen 19 | - komplexere Daten wie `["cat",["puppy","cow"],"horse",[[]],"pig",[""],"sheep"]`. 20 | 21 | Bitte beachten: In dem Rest dieses Artikels wird "String" als Synonym für "eine bestimmte Anzahl von Bytes von binären Daten" verwendet. Es wird keine besondere Kodierung betrachtet und auch nichts über den Inhalt des Strings ausgesagt. 22 | 23 | Die RLP-Kodierung funktioniert wie folgt: 24 | * Für ein einzelnes Byte innerhalb des Bereiches `[0x00, 0x7f]` erfolgt eine individuelle RLP-Kodierung. 25 | * Ist ein String 0 bis 55 Byte lang enthält die RLP-Kodierung den Wert **0x80** + die Länge des Strings, gefolgt vom Stringinhalt. Der Wertebereich des ersten Bytes ist `[0x80, 0xb7]`. 26 | * Ist ein String länger als 55 Byte, enthält die RLP-Kodierung das erste Byte mit dem Wert **0xb7** + die Länge für String+Stringlänge in Binärformat, gefolgt von der Länge des Strings, gefolgt vom Stringinhalt. Z.B. ein 1024 Byte langer String wird kodiert als `\xb9\x04\x00` gefolgt vom Stringinhalt. Der Wertebereich des ersten Bytes ist `[0xb8, 0xbf]`. 27 | * Ist die Gesamtlänge der Nutzdaten einer Liste (z.B. die kombinierte Länge aller Elemente) zwischen 0 und 55 Bytes, enthält die RLP-Kodierung das Byte mit dem Inhalt **0xc0** + die Länge der Liste, gefolgt von der Verkettung der RLP-Kodierungen der Elemente. Der Wertebereich des ersten Bytes ist `[0xc0, 0xf7]`. 28 | * Ist die Gesamtlänge der Nutzdaten einer Liste mehr als 55 Byte, enthält die RLP-Kodierung das Byte mit dem Inhalt **0xf7** + die Länge für Liste+Listenlänge in Binärformat, gefolgt von der Länge der Liste, gefolgt von der Verkettung der RLP-Kodierungen der Elemente. Der Wertebereich des ersten Bytes ist `[0xf8, 0xff]`. 29 | Als Code sieht das so aus: 30 | ```python 31 | def rlp_encode(input): 32 | if isinstance(input,str): 33 | if len(input) == 1 and chr(input) < 128: return input 34 | else: return encode_length(len(input),128) + input 35 | elif isinstance(input,list): 36 | output = encode_length(len(input),192) 37 | for item in input: output += rlp_encode(item) 38 | return output 39 | def encode_length(L,offset): 40 | if L < 56: 41 | return chr(L + offset) 42 | elif L < 256**8: 43 | BL = to_binary(L) 44 | return chr(len(BL) + offset + 55) + BL 45 | else: 46 | raise Exception("input too long") 47 | def to_binary(x): 48 | return '' if x == 0 else to_binary(int(x / 256)) + chr(x % 256) 49 | ``` 50 | ### Beispiele 51 | 52 | Der String "dog" = [ 0x83, 'd', 'o', 'g' ] 53 | 54 | Die Liste [ "cat", "dog" ] = `[ 0xc8, 0x83, 'c', 'a', 't', 0x83, 'd', 'o', 'g' ]` 55 | 56 | Der leere String ('null') = `[ 0x80 ]` 57 | 58 | Die leere Liste = `[ 0xc0 ]` 59 | 60 | Der Integer 15 = `[ 0x0f ]` 61 | 62 | Der Integer 1024 = `[ 0x82, 0x04, 0x00 ]` 63 | 64 | Die [mengentheoretischen Darstellung] (http://en.wikipedia.org/wiki/Set-theoretic_definition_of_natural_numbers) von zwei, `[ [], [[]], [ [], [[]] ] ] = [ 0xc7, 0xc0, 0xc1, 0xc0, 0xc3, 0xc0, 0xc1, 0xc0 ]` 65 | 66 | Der String "Lorem ipsum dolor sit amet, consectetur adipisicing elit" = `[ 0xb8, 0x38, 'L', 'o', 'r', 'e', 'm', ' ', ... , 'e', 'l', 'i', 't' ]` 67 | -------------------------------------------------------------------------------- /Kademlia-Peer-Selection.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Cademlia Peer Selection 3 | category: 4 | --- 5 | 6 | # Peer addresses 7 | 8 | Nodes in the P2P network are identified by 256-bit cryptographic hashes of the nodes' public keys. 9 | 10 | The distance between two addresses is the MSB first numerical value of their XOR. 11 | 12 | # Peer table format 13 | 14 | The peer table consists of rows, initially only one, at most 255 (typically much less). Each row contains at most _k_ peers (data structures containing information about said peer such as their peer address, network address, a timestamp, signature by the peer and possibly various other meta-data), where _k_ is a parameter (not necessarily global) with typical values betwen 5 and 20. 15 | 16 | This parameter, _k_, determines the redundancy of the network: the peer selection algorithm described in this page aims to maintain exactly _k_ peers in each row. If several different protocols requiring routing are used on the network, each protocol _p_ can specify its own redundancy requirement _k__p_, in which case the corresponding _k__p_ number of peers supporting that protocol are maintained. Participants must specify what protocols they support. 17 | 18 | Row numbering starts with 0. Each row number _i_ contains peers whose address matches the first _i_ bits of this node's address. The _i_+1st bit of the address must differ from this nodes address in all rows except the last one. 19 | 20 | As a matter of implementation, it might be worth internally representing all 255 rows from the outset (requiring that the _i_+1st bit be different from our node in all rows); but then considering all of the rows at the end as if they were one row. That is, we look at non empty rows at the end and treat the elements in them as if they belonged to row _i_ where _i_ is the lowest index such that the total number of all elements in row _i_ and in all higher rows, together is at most _k_. 21 | 22 | Note: there is a difference here to the original Kedemlia paper http://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf The rows with a high _i_ for us here are the rows with a low _i_ in the paper. For us, high _i_ means high number of bits agreeing, for them high _i_ mean high xor distance. 23 | 24 | # Adding a new peer 25 | 26 | A peer is added to the row to which it belongs according to the length of address prefix in common with this node. If that would increase the length of the row in question beyond _k_, the **worst** peer (according to some, not necessarily global, peer quality metric) is dropped from the row, except if it is the last row, in which case a new row _i_ + 1 is added and the elements in the old last row are split between the two rows according to the bit at the corresponding position. Note: If we followed the implementation suggestion in the previous section, then we do not need to make an exception for the last row, nor do we have to worry about splitting the last row on the implementation level. 27 | 28 | One sufficient condition for adding a peer is a signed "_add_me_" message containing the sender's peer address and network address, the addressee's peer address and a recent timestamp. 29 | 30 | # Lookup 31 | 32 | A lookup request contains a peer address (which might or might not be valid, it does not matter). The response is the peer list from the full row corresponding to the requested address (information about at most _k_ peers, or _k__p_ peers for the protocol _p_ in use). 33 | 34 | For brevity, it might be worth treating _add_me_ requests for nodes that are not already in the peer table as self-lookups and respond accordingly. 35 | 36 | The new peers are added to the peer table after which the ones in the row corresponding to the address being searched are sent the lookup request recursively, until no peers are returned that are closer to the searched address. 37 | 38 | # Joining the network 39 | 40 | Requires only one bootstrap peer, to which the new node sends an _add_me_ message and subsequently adds every node from the response to its own peer table. 41 | 42 | Thereafter, it performs a lookup of a synthetic random address from the address range corresponding to rows with indices that are smaller than the row in which the bootstrap node ended up. 43 | 44 | # Backwards compatibility mode and DoS safety 45 | 46 | Nodes can still safely dump their full peer table and accept connections from naive nodes. Overwriting the entire peer table of a node requires significant computational effort even with relatively low _k_. DoS attacks against non-naive nodes (as described in this page) require generating addresses with corresponding key pairs for each row, requiring quite a bit of hashing power. -------------------------------------------------------------------------------- /Proposal:-Extend-GetBlockHashes-with-target-hash.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Extend GetBlockHashes With Target Hash Proposal 3 | category: 4 | --- 5 | 6 | # Problem 7 | 8 | The current protocol specification does not provide the means to mitigate an infinite chain feeding attack. A malicious peer can make up arbitrary blocks on the fly, and feed their hashes indefinitely to a target, without ever linking to the existing chain. This will result in an eventual memory exhaustion and crash. The root cause is that the protocol provides no means to validate any blocks, without first pulling the entire hash chain. 9 | 10 | # Solution 11 | 12 | Peers should be able to request hashes not only backwards towards the genesis block, but forward too to some specific target hash. This would allow the downloader to start pulling actual blocks and verify them concurrently with fetching the hashes. If no peers (including the hash provider) has the blocks to back up the hashes, the chain is rejected. 13 | 14 | This forward synchronization strategy requires the capacity to locate a common ancestor block to our blockchain and that of a remote peer in order to know the joining point from which to request the hashes. This can be facilitated with the same mechanism by doing a binary search on our blockchain, requesting 1xhashes from the remote (towards its advertised head) side to see if it knows about it or not, honing in on the common ancestor. 15 | 16 | # Specification 17 | 18 | 1. Extend `GetBlockHashes` packet with an additional field: 19 | 20 | **GetBlockHashes** [`+0x03`: `P`, `srcHash`: `B_32`, `targetHash`: `B_32`, `maxBlocks`: `P`] 21 | * `targetHash`: The endpoint in a remote blockchain towards which to retrieve hashes 22 | 23 | 2. Modify `BlockHashes`'s returned hash order: 24 | 25 | * Adhere to that requested by `GetBlockHashes`, opposed to the current "hard coded" young -> old ordering 26 | 27 | The benefit of this proposal is that beside providing the means to do forward syncing, it retains the capacity to implement the currently specified reverse fetch behavior by passing the genesis block's hash to `targetHash`. This way Ethereum implementations don't have to immediately devise a new downloader strategy to cope with the update, but can function as they are until ready to evolve. 28 | 29 | # Supersedes 30 | 31 | [[Proposal: BlockHashesFromNumbers]] 32 | 33 | The main issue the `BlockHashesFromNumbers` set out to resolve was the slow download of hashes (which was stalling the synchronization), by introducing parallel fetches based on height/block-number based hash retrievals. It also inherently provided a mechanism to limit the number of potentially invalid hashes downloaded to that of the current chain's height. 34 | 35 | The current proposal however approaches the challenge from the opposite direction. By downloading hashes towards the end of a chain - after the first hash delivery - blocks can be immediately retrieved in parallel (compared to which hash downloads are insignificant in size and hence latency), so there is no need for the added complexity and potential issues with parallelizing hash downloads. Additionally, by limiting the number of pending hashes, we can also prevent any infinite chain attacks. 36 | 37 | Given that the current proposal addresses all of the issues `BlockHashesFromNumbers` aimed to fix, while being much less invasive (requires the addition of single packet field); is gracefully compatible with previous protocol implementations (they can continue to function without an algorithm update); and implementation wise is straightforward and easy to reason about; we believe it is a superior proposal. 38 | 39 | ### Critique 40 | 41 | - Closer to the present protocol than `BlockHashesFromNumbers`. 42 | - Less general and expansive than `BlockHashesFromNumbers`: it is designed for a very particular strategy and is less likely to be adaptable to future, unknown strategies. 43 | - Does not support parallel hash-chain downloading alongside forward hash-chain downloading (`BlockHashesFromNumbers` supports both). 44 | - Somewhat more complex in terms of semantics: 45 | - The notion of a series of hash going from a source hash to a destination hash is found nowhere else in the protocol or codebase. Exchanging number to/from hash is already found in the API. 46 | - Not immediately clear with edge cases (e.g. if from is genesis and to is leaf, or if from doesn't exist in the chain but leaf does, or vice-versa). `BlockHashesFromNumbers` is well-defined under all circumstances. 47 | - Somewhat more complex in terms of implementation; how to efficiently determine the fork point or common ancestor? `BlockHashesFromNumbers` would make it trivial with a binary chop. 48 | -------------------------------------------------------------------------------- /Swarm-Hash.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Swarm Hash 3 | category: 4 | --- 5 | 6 | # Introduction 7 | 8 | Swarm Hash (a.k.a. [`bzzhash`](https://github.com/ethersphere/go-ethereum/tree/bzz/bzz/bzzhash)) is a Merkle tree hash designed for the purpose of efficient storage and retrieval in content-addressed storage, both local and networked. While it is used in [Swarm](https://github.com/ethereumproject/go-ethereum/wiki/Swarm---distributed-preimage-archive), there is nothing Swarm-specific in it and the authors recommend it as a drop-in substitute of sequential-iterative hash functions (like SHA3) whenever one is used for referencing integrity-sensitive content, as it constitutes an improvement in terms of performance and usability without compromising security. For instance in the [URL Hint Protocol](./URL-Hint-Protocol). 9 | 10 | In particular, it can take advantage of parallelisms (including SMP and massively-parallel architectures such as GPU's) for faster calculation and verification, can be used to verify the integrity of partial content without having to transmit all of it. Proofs of security to the underlying hash function carry over to Swarm Hash. 11 | 12 | # Description 13 | 14 | Swarm Hash is constructed using a regular hash function (in our case, SHA3) with a generalization of Merkle's tree hash scheme. The basic unit of hashing is a _chunk_, that can be either a _leaf chunk_ containing a section of the content to be hashed or an _inner chunk_ containing hashes of its children, which can be of either variety. 15 | 16 | Hashes of leaf chunks are defined as the hashes of the concatenation of the 64-bit length (in LSB-first order) of the content and the content itself. Because of the inclusion of the length, it is resistant to length extension attacks, even if the underlying hash function is not. Note that this "safety belt" measure is extensively used in the latest edition of OpenPGP standard. It is, however, important to emphasize that Swarm Hash is obviously vulnerable to length extension attacks, but can be easily protected against them, when necessary, using similar measures in a higher layer. A possibly very profitable performance optimization (not currently implemented) is to initialize the hash calculation with the length of the standard chunk size (e.g. 4096 bytes), thus saving the repeated hashing thereof. 17 | 18 | Hashes of inner chunks are defined as the hashes of the concatenation of the 64-bit length (in LSB-first order) of the content hashed by the entire (sub-) tree rooted on this chunk and the hashes of its children. 19 | 20 | To distinguish between the two, one should compare the length of the chunk to the 64-bit number with which every chunk begins. If the chunk is exactly 8 bytes longer than this number, it is a leaf chunk. If it is shorter than that, it is an inner chunk. Otherwise, it is not a valid Swarm Hash chunk. 21 | 22 | # Strict interpretation 23 | 24 | A strict Swarm Hash is one where every chunk with the possible exception of those on the rightmost branch is of a specified length, i.e. 4 kilobytes. Those on the rightmost branch are no longer, but possibly shorter than this length. The hash tree must be balanced, meaning that all root-to-leaf branches are of the same length. 25 | 26 | The strict interpretation is unique in that only one hash value matches a particular content. The strict interpretation is only vulnerable to length extension attacks if the length of the content is a multiple of the chunk size, and the number of leaf chunks is an integer power of branching size (the fix maximum chunk size divided by hash length). 27 | 28 | A [parallelized implementation in Go](https://github.com/ethersphere/go-ethereum/tree/bzz/bzz) is available as well as [a command-line tool](https://github.com/ethersphere/go-ethereum/tree/bzz/bzz/bzzhash) for hashing files on the local filesystem using the strict interpretation. 29 | 30 | # Loose interpretations 31 | 32 | Swarm Hash interpreted less strictly may allow for different tree structures, imposing fewer restrictions or none at all. In this way, different hash values can resolve to the same content, which might have some adverse security implications. 33 | 34 | However, it might open the door for different applications where this does not constitute a vulnerability. For example, accepting single-leaf hashes in addition to strict Swarm hashes allows for referencing files without having to implement the whole thing. 35 | 36 | # References 37 | 38 | - [Merkle tree](http://en.wikipedia.org/wiki/Merkle_tree) 39 | - [Length extension attack on wikipedia](http://en.wikipedia.org/wiki/Length_extension_attack) 40 | - [IETF RFC4880](https://tools.ietf.org/html/rfc4880) 41 | - [bzzhash code](https://github.com/ethersphere/go-ethereum/tree/bzz/bzz/bzzhash) 42 | - [Swarm documentation and draft specs](https://github.com/ethereumproject/go-ethereum/wiki/Swarm---distributed-preimage-archive) -------------------------------------------------------------------------------- /[Romanian]-Limbajul-de-programare-Serpent.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Limbajul de Programare Serpent 3 | category: 4 | --- 5 | 6 | ###Operatiile limbajului de programare Serpent 7 | 8 | Aritmetica 9 | 10 | • Aritmetica normala functioneaza dupa cum ne asteptam:: x = 20 + 7 * 5 fixeaza x ca 55 11 | • Numerele negative nu exista: x = 0 - 1 seteaza x la 115792089237316195423570985008687907853269984665640564039457584007913129639935 12 | • Decimalele nu exista: x = 7 / 4 seteaza x la 1 13 | • Se poate folosi #/ si #% pentru a se putea pretinde ca numerele sunt numere intregi: x = (0-9) #/ 3 + 5 seteaza x la 2, pe cand y = (0-9) / 3 + 5seteaza y la 38597363079105398474523661669562635951089994888546854679819194669304376546647 14 | • Aritmetica deviaza 2^256: x = 3 ^ (2 ^ 254) setand x la 1 (aceasta este o consecinta a Teoremei Euler) 15 | • Folositi x = y | z, x = y & z si x = y xor z pentru operatii bitwise 16 | Variable 17 | • Variablele functioneaza ca orice fel de limbaj : x = 25 atunci y = x + 5 seteaza y la 30 18 | • Folositi x = array(n) pentru a initializa o multime de valori n 32-byte 19 | • Folositi x[i] = v pentru a seta valori in multimi si v = x[i] pentru a obtine valori in multimi 20 | • Folositi x = bytes(n) pentru a initializa un sir/multime de bytes de n bytes 21 | • Folositi setch(x,i,v) pentru a seta to set and v = getch(x,i) to get 22 | • Use array literals to declare arrays inline: x = [1,2,3] 23 | Variables are encoded into EVM code by assigning a memory index to each variable, with 32 bytes of spacing between variables. In the last example, x literally is the memory index of the start of the array, which is itself stored in a dynamically allocated slice of memory. Note that bounds-checking is not performed; array(3)[5] = 10 will have completely unknown and likely compiler-dependent consequences on code execution. 24 | Pseudovariables 25 | Ethereum provides the following pseudovariables and pseudoarrays: 26 | • block.prevhash - previous block hash 27 | • block.number - block number 28 | • block.timestamp - block timestamp 29 | • block.difficulty - block difficulty 30 | • block.coinbase - address of block miner 31 | • block.gaslimit - maximum amount of gas that can be spent in the block 32 | • tx.gasprice - amount paid by transaction for gas 33 | • tx.origin - original sender of transaction (NOT the sender of the current message, which is different in a nested call situation) 34 | • tx.gas - current amount of gas remaining 35 | • msg.datasize - length of the data provided by the message, measured as the number of complete 32-byte chunks 36 | • msg.sender - sender of the message 37 | • msg.value - value of the message 38 | • contract.balance - balance of the contract 39 | • msg.data[i] - the ith 32-byte chunk in message data 40 | • contract.storage[i] - the contract's long term storage, at index i 41 | Functions 42 | • send(to, value, gas) - sends value ether to to, allowing the computation the given amount of gas. 43 | • x = msg(to, value, gas, datastart, datalen) - sends a message to to, using the data at memory indices datastart ... datastart+datalen*32-1, with the given amount of ether and gas, and sets x to the first 32 bytes of the result. 44 | • msg(to, value, gas, datastart, datalen, outputstart, outputlen) - sends a message toto, using the data at memory indicesdatastart ... datastart+datalen*32-1, with the given amount of ether and gas, and pastes the result to memory indicesoutputstart ... outputstart+outputlen*32-1` 45 | • x = create(endowment, gas, datastart, datalen) - creates a new contract using code from the given indices in memory as above, and return the address of the contract 46 | • x = sha3(v) - returns the SHA3 of the given 32-byte value 47 | • x = byte(y,z) - sets x to the zth byte of y 48 | A lot of these commands require data to be loaded from memory; this is actually fairly easy to manage. Consider the following equivalent examples: 49 | x = msg(0xf345747062de4d05d897d62c4696febbedcb36b8, 10^18, tx.gas - 100, [10,20,30], 3) 50 | And: 51 | a = array(3) 52 | a[0] = 10 53 | a[1] = 20 54 | a[2] = 30 55 | y = array(1) 56 | msg(0xf345747062de4d05d897d62c4696febbedcb36b8, 10^18, tx.gas - 100, a, 3, y, 1) 57 | x = y[0] 58 | Conditionals and Loops 59 | Best to learn by example: 60 | if x > 5: 61 | y = 7 62 | And: 63 | x = 248 64 | while x > 1: 65 | if (x % 2) == 0: 66 | x = x / 2 67 | else: 68 | x = 3 * x + 1 69 | Note that if x > 5: y = 7 on one line is invalid. 70 | Comments 71 | x = 4 //this is a comment and does not appear in the compiled code 72 | // this also is a comment on its own line 73 | /* this style is not supported however */ 74 | Halting 75 | • stop - this keyword by itself on one line stops execution 76 | • return(x) - returns the 32 bytes of value x 77 | • return(memstart, len) - returns the memory at indices memstart ... memstart+32*len-1 78 | • suicide(a) - destroys the contract, sending all remaining balance to a 79 | Last edited by vbuterin, 3 days ago 80 | -------------------------------------------------------------------------------- /Adaptive-Message-IDs.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Message IDs 3 | category: 4 | --- 5 | 6 | ### Goal 7 | 8 | Dynamic numeric identities for the sub protocol message types rather than the current fixed id system. This way we don't have to reserve parts of the message ID space up front and have a central entity to police this space to prevent clashes. 9 | 10 | ### Overview 11 | 12 | All sub-protocol message IDs begin at 0x10 and count only those messages in the shared protocols, in alphabetical order. Sub-protocol versioning is provided in the base protocol to allow guarantees that there is consensus over the number and order of messages for each sub-protocol between peers. 13 | 14 | ### Needed Changes 15 | 16 | Wire protocol Hello package changed to (*note protocol version has changed to 1*): 17 | 18 | **Hello** 19 | [`0x00`: `P`, `p2pVersion`: `P`, `clientId`: `B`, [[`cap1`: `B_3`, `capVersion1`: `P`], [`cap2`: `B_3`, `capVersion2`: `P`], ...], `listenPort`: `P`, `nodeId`: `B_64`] First packet sent over the connection, and sent once by both sides. No other messages may be sent until a Hello is received. 20 | * `p2pVersion` Specifies the implemented version of the P2P protocol. Now must be 1. 21 | * `clientId` Specifies the client software identity, as a human-readable string (e.g. "Ethereum(++)/1.0.0"). 22 | * `cap` Specifies a peer capability name as a length-3 ASCII string. Current supported capabilities are `eth`, `shh`. 23 | * `capVersion` Specifies a peer capability version as a positive integer. Current supported versions are 35 for `eth`, and 2 for `shh`. 24 | * `listenPort` specifies the port that the client is listening on (on the interface that the present connection traverses). If 0 it indicates the client is not listening. 25 | * `nodeId` is the Unique Identity of the node and specifies a 512-bit hash that identifies this node. 26 | 27 | All `eth` sub-protocol message ids are lowered by `0x10` and have a `+` prepended to them to denote that the given ID is offset by some dynamic amount. 28 | 29 | ### Conversation overview 30 | 31 | ``` 32 | [23:11:29] gavofyork: for each shared sub protocol, in alphabetic order, you deploy the subprotocol's messages 33 | [23:11:40] gavofyork: (after the basic p2p messages) 34 | [23:12:42] gavofyork: so for two whisper-only peers, defined message types are Hello = 0x00, Disconnect, Ping, Pong, GetPeers, Peers = 0x05, WhisperMessage1 = 0x06, ... 35 | [23:13:50] gavofyork: but for two peers that have eth and shh, you'd get: Hello = 0x00, Disconnect, Ping, Pong, GetPeers, Peers = 0x05, Status = 0x06, GetTransactions = 0x07, Transactions = 0x08, GetBlockHashes = 0x09, BlockHashes = 0x0a, GetBlocks = 0x0b, Blocks = 0x0c, NewBlock = 0x0d, WhisperMessage1 = 0x0e, ... 36 | [23:14:28] Jeffrey Wilcke: so what you mean is that you negotiate which message type gets what number 37 | [23:14:34] gavofyork: exactamundo 38 | [23:14:45] Jeffrey Wilcke: right interesting 39 | [23:15:12] gavofyork: no arguing over what protocol gets what message-id space 40 | [23:15:25] gavofyork: avoids any central registry or anything 41 | [23:15:33] Jeffrey Wilcke: so receiving and sending might be completely different "numbers" but have the same meaning 42 | [23:15:40] gavofyork: yup 43 | [23:15:56] gavofyork: will make wire protocol analysis slightly harder 44 | [23:16:02] gavofyork: though that's not necessarily a bad thing 45 | [23:16:33] Jeffrey Wilcke: Ok so you tell a node that GetBlockHahses = 0x09 46 | [23:17:37] Jeffrey Wilcke: GetBlockHashes internally is say 0x03. We give it an array with [0x03, 0x09] meaning "map GetBlockHashes to 0x09" or "when you receive 0x09 I mean GetBlockHashes". 47 | [23:18:12] gavofyork: don't even need to do that 48 | [23:18:21] gavofyork: so we'll need a map internally 49 | [23:18:28] gavofyork: but there's no need to ever serialise it 50 | [23:18:46] Jeffrey Wilcke: No, well you have to let the other know how you understand messages 51 | [23:18:54] Jeffrey Wilcke: meaning that get hashes = 9 52 | [23:19:01] gavofyork: "for each shared sub protocol, in alphabetic order, you deploy the subprotocol's messages" 53 | [23:19:22] gavofyork: both form natural consensus on the alphabetic order of the shared subprotocols 54 | [23:19:28] gavofyork: just from both Hello packets 55 | [23:20:03] gavofyork: the one thing we should bring in is subprotocol versioning 56 | [23:20:33] Jeffrey Wilcke: but how do we negotiate over the numbering? 57 | [23:20:43] gavofyork: that is the negotiation :) 58 | [23:21:04] gavofyork: you know the exact message type set & order in each subprotocol 59 | [23:21:14] gavofyork: and you know the order they should be counted in 60 | [23:21:26] gavofyork: and you know where to count from 61 | [23:21:28] Jeffrey Wilcke: of course, but how do negotiate over the subprotocol 62 | [23:21:33] gavofyork: oh 63 | [23:21:36] gavofyork: that's in the Hello packet 64 | [23:21:45] gavofyork: that contains the supported subprotocols 65 | [23:21:52] gavofyork: e.g. A <=> B: 66 | [23:21:53] Jeffrey Wilcke: aaah i follow 67 | [23:21:56] gavofyork: ok 68 | [23:22:11] Jeffrey Wilcke: right ok. i thought you meant alphabetical in the _messages_ 69 | [23:22:19] Jeffrey Wilcke: ok makes sense 70 | ``` -------------------------------------------------------------------------------- /Clearinghouse.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Clearinghouse 3 | category: 4 | --- 5 | 6 | ### Introduction 7 | 8 | In some type of financial instruments like Futures (but not Forwards), parties are guaranteed against credit losses resulting from the counterparty default by a "clearinghouse". Essentially, a clearinghouse provides this guarantee via a procedure in which the gains and losses that accrue on daily basis throughout the life of a contract are converted into actual cash (daily settlement of gains or losses). 9 | 10 | ### Daily Settlement 11 | 12 | As explained a daily settlement is the actual conversion into cash of daily gains or losses. This procedure is called **daily settlement** or **marking to market** and it is best illustrated via an actual example. 13 | 14 | Let's assume two parties enter a Future contract to buy some underlying with a settlement price of 100 USD in a month time (not to be confused with the daily settlement procedure). In order to enter this contract the clearinghouse will set an **initial margin requirement**both the future traders (in this case the party that is going to buy the underlying or the **holder of the long position** and the party that is selling the underlying or the **holder of the short position**) will have to deposit upfront (notice in the context of clearinghouse operations **margin** does not have the same meaning of leverage trading on borrowed money that is used elsewhere). Our initial margin requirement will be 5 USD per contract and will be deposited into a clearinghouse **margin account** associated with the specific contract. 15 | 16 | During the life of the contract as the margin account balances change, the parties involved in the contract must maintains their corresponding balances above a level called the **maintenance margin requirement** again decided by the clearinghouse and usually lower than the initial margin. 17 | 18 | At the end of each day, the clearinghouse will provide a **settlement price** (usually an average price of any trades that happened during the day) and execute the **mark-to-market** process (daily settlement). 19 | 20 | In our specific example, let's assume the maintenance margin has been set at 3 USD per contract and buying party is entering 10 contract (in other words he will have to deposit an initial margin of 50 USD. We shall also assume money cannot be withdrawn from the clearinghouse (i.e. excess funds). The initial price will be 100 USD (the price of the future contract). 21 | 22 | A complete example, is provided in the table below. Notice the two panels report the daily balances of the two parties (long and short). 23 | 24 | 25 | #### Panel A. Holder of Long Position of 10 Contracts 26 | 27 | |Day (1)|Beginning Balance (2)|Funds Deposited (3)|Settlement Price (4)|Futures Price Change (5)|Gain/Loss (6)|Ending Balance (7)| 28 | |:----------:|-------------:|------:|---:|---:|---:|---:| 29 | |0|0|50|100.0| - | - |50| 30 | |1|50|0|99.20| -0.80| -8|42| 31 | |2|42|0|96.00| -3.20| -32|10| 32 | |3|10|40|101.00|5.00|50|100| 33 | |4|100|0|103.50|2.50|25|125| 34 | |5|125|0|103.00| -0.50| -5|120| 35 | |6|120|0|104.00|1.00|10|130| 36 | 37 | 38 | #### Panel B. Holder of Short Position of 10 Contracts 39 | |Day (1)|Beginning Balance (2)|Funds Deposited (3)|Settlement Price (4)|Futures Price Change (5)|Gain/Loss (6)|Ending Balance (7) 40 | |:----------:|-------------:|------:|---:|---:|---:|---:| 41 | |0|0|50|100.0| -| -|50 42 | |1|50|0|99.20| -0.80|8|58 43 | |2|58|0|96.00| -3.20|32|90 44 | |3|90|0|101.00|5.00| -50|40 45 | |4|40|0|103.50|2.50| -25| 15 46 | |5|15|35|103.00| -0.50| 5|55 47 | |6|55|0|104.00|1.00| -10|45|} 48 | 49 | The day the contract is entered will be referred as ''Day 0'', both parties will deposit an initial margin of 50 USD and we shall assume that on ''Day 1'' the future price moves down to 99.20 USD as indicated in Column 4 of Panel A. In Column 5 we can see the Future price change -0.80 (99.20 - 100) and this amount is multipled by the number of contract, 10, to obtain the number in Column 6: -0.80 x 10 = - 8 USD. The ending balance is shown in Column 7 and it is the beginning balance plus/minus any gain/loss. The ending balance on Day 1 for the Holder of the Long Position is 42 USD and it is above the maintenance margin of 30 USD so no extra deposit is required. 50 | 51 | ### Ethereum clearinghouse implementation and logic 52 | 53 | * does it apply to all contracts? 54 | * which flag should be set to enable clearinghouse? 55 | * how are the money/ether debited/credited? Push or pull system? 56 | * Normally clearinghouses use an average daily price (not close price). How to implement? THIS IS IMPORTANT TO AVOID PRICE MANIPULATION ethereum would be even more vulnerable than classic clearinghouse. 57 | * what happens in case of default (failed margin call)? Reputation system? 58 | * many contracts will require an external price feed (i.e. Gold price from CME or LIBOR interest rates). How do we feed them? 59 | * can money being withdrawn from the clearinghouse (i.e. excess funds/gains)? Would be simpler if this was not the case. 60 | * what if the parties really want to exchange the underlying? i.e. no cash/ether settlement? (NOT SPECIFIC TO CLEARINGHOUSE) 61 | * losses/gains are magnified by the leverage inherently provided by the clearinghouse. ACCEPTABLE FOR ETHEREUM? NOTICE ALTHOUGH A FULL SUM DO NOT NEED TO BE DEPOSITED UPFRONT. 62 | 63 | ### Code reference sample 64 | -------------------------------------------------------------------------------- /ÐΞVp2p-Wire-Protocol.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: DEV P2P Wire Protocol 3 | category: 4 | --- 5 | 6 | Peer-to-peer communications between nodes running Ethereum/Whisper/&c. clients are designed to be governed by a simple wire-protocol making use of existing ÐΞV technologies and standards such as [RLP](./RLP) wherever practical. 7 | 8 | This document is intended to specify this protocol comprehensively. 9 | 10 | ### Low-Level 11 | 12 | ÐΞVp2p nodes communicate by sending messages using RLPx, an encrypted and authenticated transport protocol. Peers are free to advertise and accept connections on any TCP ports they wish, however, a default port on which the connection may be listened and made will be 30303. 13 | Though TCP provides a connection-oriented medium, ÐΞVp2p nodes communicate in terms of packets. 14 | RLPx provides facilities to send and receive packets. For more information about RLPx, refer to the [protocol specification](https://github.com/ethereum/devp2p/tree/master/rlpx.md). 15 | 16 | ÐΞVp2p nodes find peers through the RLPx discovery protocol DHT. Peer connections can also be initiated by supplying 17 | the endpoint of a peer to a client-specific RPC API. 18 | 19 | ### Payload Contents 20 | 21 | There are a number of different types of payload that may be encoded within the RLP. This ''type'' is always determined by the first entry of the RLP, interpreted as an integer. 22 | 23 | ÐΞVp2p is designed to support arbitrary sub-protocols (aka _capabilities_) over the basic wire protocol. Each sub-protocol is given as much of the message-ID space as it needs (all such protocols must statically specify how many message IDs they require). On connection and reception of the `Hello` message, both peers have equivalent information about what subprotocols they share (including versions) and are able to form consensus over the composition of message ID space. 24 | 25 | Message IDs are assumed to be compact from ID 0x10 onwards (0x00-0x10 is reserved for ÐΞVp2p messages) and given to each shared (equal-version, equal name) sub-protocol in alphabetic order. Sub-protocols that are not shared are ignored. If multiple versions are shared of the same (equal name) sub-protocol, the numerically highest wins, others are ignored. 26 | 27 | ### P2P 28 | 29 | **Hello** 30 | `0x00` [`p2pVersion`: `P`, `clientId`: `B`, [[`cap1`: `B_3`, `capVersion1`: `P`], [`cap2`: `B_3`, `capVersion2`: `P`], `...`], `listenPort`: `P`, `nodeId`: `B_64`] First packet sent over the connection, and sent once by both sides. No other messages may be sent until a Hello is received. 31 | * `p2pVersion` Specifies the implemented version of the P2P protocol. Now must be 1. 32 | * `clientId` Specifies the client software identity, as a human-readable string (e.g. "Ethereum(++)/1.0.0"). 33 | * `cap` Specifies a peer capability name as a length-3 ASCII string. Current supported capabilities are `eth`, `shh`. 34 | * `capVersion` Specifies a peer capability version as a positive integer. Current supported versions are 34 for `eth`, and 1 for `shh`. 35 | * `listenPort` specifies the port that the client is listening on (on the interface that the present connection traverses). If 0 it indicates the client is not listening. 36 | * `nodeId` is the Unique Identity of the node and specifies a 512-bit hash that identifies this node. 37 | 38 | **Disconnect** 39 | `0x01` [`reason`: `P`] Inform the peer that a disconnection is imminent; if received, a peer should disconnect immediately. When sending, well-behaved hosts give their peers a fighting chance (read: wait 2 seconds) to disconnect to before disconnecting themselves. 40 | * `reason` is an optional integer specifying one of a number of reasons for disconnect: 41 | * `0x00` Disconnect requested; 42 | * `0x01` TCP sub-system error; 43 | * `0x02` Breach of protocol, e.g. a malformed message, bad RLP, incorrect magic number &c.; 44 | * `0x03` Useless peer; 45 | * `0x04` Too many peers; 46 | * `0x05` Already connected; 47 | * `0x06` Incompatible P2P protocol version; 48 | * `0x07` Null node identity received - this is automatically invalid; 49 | * `0x08` Client quitting; 50 | * `0x09` Unexpected identity (i.e. a different identity to a previous connection/what a trusted peer told us). 51 | * `0x0a` Identity is the same as this node (i.e. connected to itself); 52 | * `0x0b` Timeout on receiving a message (i.e. nothing received since sending last ping); 53 | * `0x10` Some other reason specific to a subprotocol. 54 | 55 | **Ping** 56 | `0x02` [] Requests an immediate reply of `Pong` from the peer. 57 | 58 | **Pong** 59 | `0x03` [] Reply to peer's `Ping` packet. 60 | 61 | **NotImplemented (was GetPeers)** 62 | `0x04` 63 | 64 | **NotImplemented (was Peers)** 65 | `0x05` 66 | 67 | ### Node identity and reputation 68 | 69 | The identity of a ÐΞVp2p node is a secp256k1 public key. 70 | 71 | Nodes are free to store ratings for given IDs (how useful the node has been in the past) and give preference accordingly. Nodes may also track node IDs (and their provenance) in order to help determine potential man-in-the-middle attacks. 72 | Clients are free to mark down new nodes and use the node ID as a means of determining a node's reputation. 73 | 74 | ### Session Management 75 | 76 | Upon connecting, all clients (i.e. both sides of the connection) must send a `Hello` message. Upon receiving the `Hello` message and verifying compatibility of the network and versions, a session is active and any other P2P messages may be sent. 77 | 78 | At any time, a Disconnect message may be sent. -------------------------------------------------------------------------------- /[Japanese]-Whisper-（ウィスパー）.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Whisper 3 | category: 4 | --- 5 | 6 | ユースケース 7 | 8 | * DApps(分散形アプリ)は、互いに少量の情報を出しあう必要があり、一定時間情報を公開したまま保持する。 9 | 例えば分散型の通貨換算所を目指すDAppでは、あるレートで通貨を売って欲しいという要求を記録するために公開された情報を利用する。 10 | このような使い方においては、何十分何日間と情報を公開している状態が続く。 11 | オファーは決して取引を強制するものではなく、ただ潜在的な取引の始まりを示唆しているだけである。 12 | 13 | * 分散形アプリは、あるトランザクションにおいて究極的に協力する関係を持つために 14 | お互いに信号を送り合う必要がある。 15 | 例えば分散形の通貨取引所アプリは、1つの取引を作成する前に（交換所に依っては２つの取引）、 16 | オファーを調整するためにお互いの信号を利用する必要がある。 17 | 18 | * リアルタイムではない情報を提供する必要がある、もしくは互いに 19 | 一般的な通信を行う必要がある分散形のアプリの例は、例えば小さなチャットルームの部屋だ。 20 | 21 | * 分散形のアプリは、お互いのことを何も分からないがハッシュだけは分かる2つの通信者に対して 22 | 見えない通信を提供する必要がある。(全体のネットワークを通じた解析に対して合理的な拒否を行う) 23 | 不正告発者が、著名なジャーナリストにコンタクトをとり、少量の証明可能な情報をやりとりし、 24 | そして、何か他のプロトコル(Swarm, かもしれない)によって、大量の通信を出来るようにするある分散形のアプリかもしれない。 25 | 26 | 一般的にトランザクションを考えると、出来事が記された記録がなかったとしても、 27 | あらゆる必要な物事は、言ったことや、自動執行や、状態の変更に結びついている。 28 | 29 | 仕様 30 | 31 | * Low-level 低位のAPIは分散形アプリにのみ提供され、ユーザーには決して提供されない。 32 | * Low-bandwidth 低位の通信帯は大きなデータの通信には利用されない。 33 | * Uncertaing-latency 不確実な遅れはRTCには利用されない 34 | * Dark　パケットを追跡するための方法は無い。 35 | * Typical Usage: 36 | ** Low-latency 遅延の少ないメッセージは1対1や、1対Nでのメッセージを送る際に使われる。 37 | ** High-latency 遅延は大きいが、生存時間(TTL)の長いメッセージは、メッセージを公開する際に使用される。 38 | メッセージは64Kバイト未満であり、一般的には約256バイトである。 39 | 40 | 既存の解決策 41 | * UDP: APIレベルでよく似ていて、ネイティブのマルチキャスティング。生存時間は設定されておらず、セキュリティや、プライバシーの保護もない。 42 | * [0MQ](http://zeromq.org/): 分散形のメッセージシステム。何もプライバシーの保護機能は備わっていない。 43 | * [Bitmessage](https://bitmessage.org/wiki/Main_Page): P2Pのネットワーク上でのメッセージ交換システムと似ている。 44 | 高位のプロトコルで、決まった生存期間(TTL)を持ち、スループットに対しての調整機能を持たない。 45 | * [TeleHash](https://github.com/telehash/telehash.org/blob/master/network.md#paths): 安全な通信を目指したRTC通信。Bittorrentの方法と似ている。（修正版Kademila Techを使用), 46 | だが与えられたハッシュのピアーを見つけるよりも、与えられたハッシュの受信者を見つける。 47 | DHTを使って決定論的なルーティングを行うため、それゆえに大規模な攻撃に対しての単純で解析的なパケット解析攻撃に脆弱である、 48 | 接続を主目的としているため、生存期間(TTL）や、非同期的な通信の公開のために作られていない。 49 | * [Tox](https://github.com/irungentoo/toxcore/blob/master/docs/updates/DHT.md): 高位(IM & AV チャット)の補完を目的として作られた。 50 | 51 | ### 基本的なデザイン 52 | 53 | Uses the `"shh"` protocol string of ÐΞVP2P. 54 | 55 | 残りはもうじき公開される。一度プロトタイピングは完了した。by Gav 56 | ### トラフィック解析を出来なくすることが考慮されている。 57 | 58 | （Lokiverloren より） 59 | 既に存在する位置情報が覆い隠されているインスタントメッセージサービスを目的としている全てのプロトコルは、 60 | ルーティングに対処するための複雑な問題を抱えている。 61 | 62 | Bitmessageプロトコルでは、メッセージを匿名でネットワークに公開するが、 63 | 適切な受信者がどうやって復号化して受け取るのかを知る必要がある（他のメッセージツールと丁度同じように）。 64 | だが、メッセージを保存後、ユーザーが新しいメッセージを得られたことを知る事が出来る。 65 | 問題は全体のネットワークに公開される情報量が著しく増えるに連れて、 66 | 理想的な状態では用意にアクセスされるべきではない暗号化された通信が全体のネットワークに公開されることだ。 67 | 68 | 上記のどの通信プロトコルもとりわけメッセージの出処とその行き先を隠すということについての方法がない。 69 | そのため、私はウィスパープロトコルの1つの主目的は送信者と受信者の位置情報を匿名化して、 70 | 中継点からにその他、もしくは双方との接続を不可能ではないにしても難しくすることである。 71 | 72 | Tor システムは2つのノードの間でお互いの位置情報を知ること無く接続を確立する事が出来るプロトコルを持っている。 73 | それは隠されたサービスを提供するために使われているランデブープロトコルによるものである。 74 | この記事の読者の大半は、既にどのようにして動くかを知っているだろう。 75 | だがどのようにして動いているかといえば、隠されたサービス（TCP/IP通信中のポートを聞くサーバーと同様のサービス) 76 | が通信紹介者のノード達の間からランダムな番号を選び出す（通常は6であると筆者は思う）。 77 | そのためには、一般的な3-hopで届く導入者への接続を確立し、 78 | ユーザーが隠されたサービスとのコネクションを確立しようと望んだ時には、 79 | 特定の公開鍵と組となる隠されたサービスへと接続しようとするリクエストを発信する必要がある。 80 | 81 | どのようにしてリクエストが伝播するのかについては確かな確信が無いが、 82 | 明らかに円形の回線かランデブー型のTor導入者のノードが、 83 | どのノードが回線を創りだそうとしているのかを知っていることによって、 84 | 隠されたサービスへの接続のためのリクエストの伝播が為されている。 85 | 一旦クライアントが有効な接続可能なランデブーノードを知れば、コネクションを確立し、 86 | 隠されたサービスへランデブーノードを中継して、トラフィックを持つことが出来るようにリクエストを送る 87 | 88 | 通信接続のプロトコルを隠すための実装としてあまり良いもので内容に思う。 89 | 何故ならば、クライアントのノードとしてノード間を伝わっていくために異なるIDが必要となるためだ。 90 | 同様の原理はEthereum にも当てはまる。 91 | 92 | しかしながらランデブーを使用することによって、再度互いのことを知っているノード間の接続 93 | （たとえお互いのアカウントやIDや通信開始者を知らないにしても）が出来るようにし、 94 | 3hop 回線を形成するよりも何か。 95 | 96 | Tor上の出口となるノードへと繋がる回線を形成するためには、クライアントが通信中のホップのリレーのIDを知る事が危険でない 97 | だが、そのためには、"ネットワーク内で" 位置情報を難読化するセキュリティに対しての脆弱性がある。 98 | 貴方のルーターのIDと、貴方のEthereumのIDを結びつける（筆者は明白にイーサリウムのノードが実行する、ルーティングの機能を公開する必要があると考える。）ランデブーノードに接続する際に、あなたの位置情報をランデブーに対して公開しない。 99 | そしてランデブーノードは隠されたサービスの位置情報を知ることもない。 100 | そして、ルーターが創りだされる公開ディレクトリの情報だけを必要とするこれらの通信を確立する。 101 | 102 | 攻撃者にとって結果として手に入る情報ではなく、 103 | 貴方のIPアドレスに関係するサーバーを直接調べることによって明かされてしまうかもしれない。 104 | 105 | この議論に対して私は下記を述べたい。 106 | 107 | 1. ウィスパーのプロトコルはTorのような位置情報を匿名化するシステムを通して動く必要があると、上記の事実は示唆している。 108 | それだけでなく、Torが隠されたサービスのために用いているランデブープロトコルを形成する形式を用いなければならない。 109 | 110 | 2. しかしながら、Torは元来ウェブサーバーが貴方のIPアドレス（セッションのクッキーと記録と関連する）を記録することを防ぐための手段を第一義として設計された。そして第二義的に、TCP/IPルーティング（ポート）の通信の同様の手段を実装するための機能が付け加えられた。ランデブープロトコルを形成して位置情報を匿名化するという文脈の中で最初の目的を達成するために残った中間生成物が、3hop ノードとコネクションを利用する方法の形成へと繋がった。そしてコネクションが無いセッションのようなHTTPで使われているプロトコルよりもむしろオープンなまま残っている。 111 | そこで私が提言したいことは、特定のコネクションが必要であるために、そこには匿名化のプロセスを混ぜあわせる機会がある。その機会を使うことによって、悪意あるノードが攻撃者に対してデータを集めるためのトラフィックの解析があった場合に、 112 | コネクションを一層隠されたものに出来るのではないかということだ。 113 | 114 | 例えば、ブラウザとサーバー間のような通常の通信では再び接続を確立するために遅れが生じるので、通信は開いたままで 115 | 更にリクエストを送る場合にはセッションのクッキーを保管しておく。セッションのクッキーを保存しておく代わりに、クライアントが隠され隠されたノードへのコネクションの方法を変更することが出来る。 116 | そのコネクションでは秘密鍵を共有して通信する代わりに、多数の異なる回線を通ったデータの断片、そして受信者は断片がオリジナルのパケットを構成できる様になるまで待たなければならない。確かに(ウィスパーに関連しているだけでなく他の分散形のデータストレージプロトコルにおいても)大きな通信や、様々なパートに分かれた通信においてプロセスを取った匿名化の方法を変えることによって、一層トラフィック解析データを難読化するだろう。 117 | 118 | メッセージシステムであっても、分散形のファイルシステムであっても、 119 | 只送信されるデータの大きさに対処する必要がある違いだけで、本質的に同様の考察が当てはまる。 120 | 121 | どのようにしてルーティングを進めるかを決定するための評価指標は、通信遅延だ。 122 | 幾つかの目的に対しては通信遅延が少ないことが求められる、他のいくつかの目的に対しては、 123 | セキュリティが高いことの方が重要である。 124 | プロセスの流れの中でパーツに分類された際に、パーツから全体のパッケージへとコンバートするためには、 125 | 全てのパーツが揃っている際にだけ出来るとすることによって、セキュリティを一層向上させる事が出来る。 126 | 一部のパートが傍受されて、完全なメッセージでなかった際には、 127 | データを組み合わせることは不可能で暗号解析の目的にさえも使用することが出来ない。 -------------------------------------------------------------------------------- /Generalized_Merkle_DHT.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Generalized Merkle DHT 3 | category: 4 | --- 5 | 6 | As blockchain technologies move beyond the "1.0" model of every node processing every transaction, and a more diverse ecosystem including "light clients" that achieve security by downloading only a small portion of the blockchain and extracting the rest of the data on-demand through hash-based authentication comes into play, and particularly in the long term as scalability models essentially turn _every_ node into a light client, there arises the need to develop a strong, robust and effective networking infrastructure to handle the load. Ideally, the core technology should be built to be maximally generalized, so that the same core code and network can be used for multiple blockchain, as well as non-blockchain, applications. 7 | 8 | The kernel of the work is the distributed hash table, as pioneered by projects such as [Kademlia](http://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf) and implemented in BitTorrent and now IPFS. The distributed hash table uses a network where nodes are organized to point to other nodes in such a way that, given a value `v` with a key `k`, a node knowing `k` can quickly discover the location of the node that stores `v`; usually we say `k = H(v)` for some hash function (eg. SHA256, SHA3). Theoretically, such a DHT can be used to very easily enable light client support for _any_ blockchain protocol with sufficiently high degrees of Merkle tree support, and even use one codebase for light and full clients, the only difference being that light clients would use the DHT as a "hard drive" in place of their actual computer disks. 9 | 10 | However, this model has an important flaw: it requires `log(n)` lookups in order to receive a proof. Hence, if the network latency is 500ms, and a tree has a depth of 10 nodes, then the total lookup and verification will take at least five seconds. Simpler light client protocols tend to avoid this obstacle by simply having a "request-response" model: light node A wants a proof for X, full node B provides _all_ relevant Merkle nodes, and light node A verifies. The DHT approach has the benefit of extreme generality; the dedicated Merkle proof approach has the benefit of higher speed. However, we can arguably combine the benefits of both. 11 | 12 | The protocol at base level is as follows: suppose there exists a program `P` with an initial state `S_0`, run in a virtual machine which has access to an `INVHASH` ("inverse hash") opcode. `P` may be a simple iterative descent script to fetch a Merkle tree node, or it may be a complete proof of transaction correctness, or even a search process. Suppose there exists a light client which wants `P(h)` given some "root hash" value `h`, together with a proof; we consider `h` part of `S_0`. The light client initializes `D <- {}`, `S <- S_0` and repeatedly undergoes the following process: 13 | 14 | 1. Run `P` until it encounters either an end state (in which case exit) or an `INVHASH` opcode with argument `k`, such that the node does not know a value `v` such that `sha3(v) = k`. 15 | 2. Let `S_c` be the current state after this point. Set `S <- S_c` 16 | 3. Send a message `(P, S_c)` to another node on the network, using `k` as a pointer to finding that node (eg. via the Kademlia algorithm) 17 | 4. That node initializes `D' <- {}`, and runs `P` until it encounters an `INVHASH` opcode with argument `k`, such that the node does not know a value `v` such that `sha3(v) = k`. It immediately halts and replies back with `D'` 18 | 5. Merge `D'` into `D` (ie. set `D <- D U D'`), and go to step 1. 19 | 20 | Essentially, the light client repeatedly asks a node on the network "run this program as long as you can until you find a value you cannot resolve, then reply back to me with the values you did manage to resolve", and keeps on accumulating nodes in its hash until eventually it can locally run through the entire program. 21 | 22 | This process takes: 23 | 24 | * Linear time in the number of computational steps (as every step of execution, assuming honesty, is computed a maximum of exactly twice, once by the local node and once by the remote node) 25 | * Anywhere from constant to linear time in the number of `INVHASH` executions, depending on what portion of all available key/value pairs every node has and how well they are clustered 26 | 27 | It can be viewed as a superset of a DHT and Bitcoin-style SPV protocols, and is adaptable to state get operations, transaction proofs, receipt lookups, search operations, trie next/prev operations, proofs of non-membership, and generally any kind of computation on blockchain data. If implemented correctly it can be used for both Ethereum, Bitcoin proposals such as tree chains, and even parts of a decentralized search engine. 28 | 29 | In order to prevent abuse, the program execution instance will naturally need to have a gas limit. There are two ways of doing this: 30 | 31 | 1. Have a hard fixed limit (eg. 1 million), and rely on the same anti-DDoS techniques that are normally used for messages that have a bounded response time. 32 | 2. Require each `(P, S)` message to specify a gas limit, and require either proof of work or a micropayment in exchange. If there is not enough gas, then simply return just as if you have encountered an `INVHASH` you cannot resolve. However, this protocol may not be optimal when there is high uncertainty about when unresolvable `INVHASH` operations will pop up. 33 | 3. The sending party creates a ticket which says "I am willing to pay $X per step". The receiving party signs their reply message. The sender must then micro-pay after the fact. If the sender does not do so honestly, then the receiver can "go to blockchain court" and have the auditing contract verify the correct payment to be made, and if the correct payment was not in fact made force the sender to pay a fine. -------------------------------------------------------------------------------- /Standardized_Contract_APIs.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Standardized Contract APIs 3 | category: 4 | --- 5 | 6 | Although Ethereum allows developers to create absolutely any kind of application without restriction to specific feature types, and prides itself on its "lack of features", there is nevertheless a need to standardize certain very common use cases in order to allow users and applications to more easily interact with each other. This includes sending currency units, registering names, making offers on exchanges, and other similar functions. A standard typically consists of a set of function signatures for a few methods, eg. `send`, `register`, `delete`, providing the set of arguments and their formats in the [Ethereum contract ABI](./Ethereum-Contract-ABI) language. 7 | 8 | The standards described below have sample implementations available [here](https://github.com/ethereumproject/dapp-bin/tree/master/standardized_contract_apis). 9 | 10 | All function names are in lower camelCase (eg. `sendCoin`) and all event names are in upper CamelCase (eg. `CoinTransfer`). Input variables are in underscore-prefixed lower camelCase (eg. `_offerId`), and output variables are `_r` for pure getter (ie. constant) functions, `_success` (always boolean) when denoting success or failure, and other values (eg. `_maxValue`) for methods that perform an action but need to return a value as an identifier. Addresses are referred to using `_address` when generic, and otherwise if a more specific description exists (eg. `_from`, `_to`). 11 | 12 | ## Transferable Fungibles (see [ERC 20](https://github.com/ethereum/EIPs/issues/20) for the latest) 13 | 14 | Also known as tokens, coins and sub-currencies. 15 | 16 | 17 | ## TF Registries (see [ERC 22](https://github.com/ethereum/EIPs/issues/22) for the latest) 18 | 19 | Token registries contain information about tokens. There is at least one global registry (though other may create more like the global Registry) to which you can add your token. Adding your token to it would increase the experience of the user that the GUI Client can use or not. 20 | 21 | ## Registries 22 | 23 | Registries (eg. domain name systems) have the following API: 24 | 25 | ### Methods 26 | #### reserve 27 | 28 | ```js 29 | reserve(string _name) returns (bool _success) 30 | ``` 31 | Reserves a name and sets its owner to you if it is not yet reserved. 32 | 33 | #### owner 34 | 35 | ```js 36 | owner(string _name) constant returns (address _r) 37 | ``` 38 | Get the owner of a particular name. 39 | 40 | #### transfer 41 | 42 | ```js 43 | transfer(string _name, address _newOwner) 44 | ``` 45 | Transfer ownership of a name. 46 | 47 | #### setAddr 48 | 49 | ```js 50 | setAddr(string _name, address _address) 51 | ``` 52 | 53 | Set the primary address associated with a name (similar to an A record in traditional DNS.) 54 | 55 | #### addr 56 | 57 | ```js 58 | addr(string _name) constant returns (address _r) 59 | ``` 60 | Get the primary address associated with a name. 61 | 62 | #### setContent 63 | 64 | ```js 65 | setContent(string _name, bytes32 _content) 66 | ``` 67 | 68 | If you are the owner of a name, sets its associated content. 69 | 70 | #### content 71 | 72 | ```js 73 | content(string _name) constant returns (bytes32 _r) 74 | ``` 75 | 76 | Get the content associated with a name. 77 | 78 | #### setSubRegistrar 79 | 80 | ```js 81 | setSubRegistrar(string _name, address _subRegistrar) 82 | ``` 83 | 84 | Records the name as referring to a sub-registrar at the given address. 85 | 86 | #### subRegistrar 87 | 88 | ```js 89 | subRegistrar(string _name) constant returns (address _r) 90 | ``` 91 | Gets the sub-registrar associated with the given name. 92 | 93 | #### disown 94 | 95 | ```js 96 | disown(string _name) 97 | ``` 98 | 99 | Relinquishes control over a name that you currently control. 100 | 101 | ### Events 102 | 103 | #### Changed 104 | 105 | ```js 106 | event Changed(string name, bytes32 indexed __hash_name) 107 | ```` 108 | 109 | Triggered when changed to a domain happen. 110 | 111 | 112 | ## Data feeds 113 | 114 | The data feed standard is a _templated standard_, ie. in the below descriptions one should be free to replace `` with any desired data type, eg. `uint256`, `bytes32`, `address`, `real192x64`. 115 | 116 | ### Methods 117 | #### get 118 | 119 | ```js 120 | get(bytes32 _key) returns ( _r) 121 | ``` 122 | 123 | Get the value associated with a key. 124 | 125 | #### set 126 | 127 | ```js 128 | set(bytes32 _key, _value) 129 | ``` 130 | 131 | Set the value associated with a key if you are the owner. 132 | 133 | #### setFee 134 | 135 | ```js 136 | setFee(uint256 _fee) 137 | ``` 138 | 139 | Sets the fee. 140 | 141 | #### setFeeCurrency 142 | 143 | ```js 144 | setFeeCurrency(address _feeCurrency) 145 | ``` 146 | 147 | Sets the currency that the fee is paid in 148 | 149 | The latter two methods are optional; also, note that the fee may be charged either in ether or subcurrency; if the contract charges in ether then the `setFeeCurrency` method is unnecessary. 150 | 151 | 152 | ## Forwarding contracts (eg. multisig) 153 | 154 | Forwarding contracts will likely work very differently depending on what the authorization policy of each one is. However, there are some standard workflows that should be used as much as possible: 155 | 156 | ### Methods 157 | #### execute 158 | 159 | ```js 160 | execute(address _to, uint _value, bytes _data) returns (bytes32 _id) 161 | ``` 162 | 163 | Create a message with the desired recipient, value and data. Returns a "pending ID" for the transaction. 164 | 165 | #### confirm 166 | 167 | ```js 168 | confirm(bytes32 _id) returns (bool _success) 169 | ``` 170 | 171 | Confirm a pending message with a particular ID using your account; returns success or failure. If enough confirmations are made, sends the message along. 172 | 173 | Access policies can be of any form, eg. multisig, an arbitrary CNF boolean formula, a scheme that depends on the _value_ or _contents_ of a transaction, etc. --------------------------------------------------------------------------------