A message from our CEO about the future of Stack Overflow and Stack Exchange. Read now.
16

Its Ethereum Request for Comments Ethererum Specific of wiki/Request_for_Comments This is interesting


12

The protocol requires that transactions from a single account are executed in nonce order. It's still possible for an account to have many pending transactions, and as long as the nonces are contiguous, a miner can include as many of them as desired in a single block, as long as they're executed in order. There's no guarantee of ordering of transactions ...


11

RLP was chosen because of (1) simplicity of implementation, and (2) guaranteed absolute byte-perfect consistency. Source is Ethereum Wiki: RLP is intended to be a highly minimalistic serialization format; its sole purpose is to store nested arrays of bytes. Unlike protobuf, BSON and other existing solutions, RLP does not attempt to define any ...


11

whisper is part both the go and c++ clients. It is a fully functional implementation. swarm is being actively developed by the go-team. See the Devcon1 talk for the big picture. See the issues labeled 'swarm' on github. POC1 will be public and integration to Mist will start after some more serious network integration testing. Work towards using IPFS as ...


9

As reminded in the first comment from Richard, smart contracts have to be deterministic because each nodes of the network have to be able to find the same result given the same input for a contract method. Otherwise each node that executes the contract method to validate the transaction would end with different results and no consensus would be possible. ...


9

Yes you are right there is a lot of standards but the majority of them are proposals and not standards that have been adopted. You can check all the Ethereum Improvement Proposals (EIPs). ERC-190 This ERC proposes a specification for Ethereum smart contract packages. Packaging is a core piece of modern software development which is missing from the ...


7

Currently, no EVM instructions are needed at all - a transaction between two externally owned accounts transfers value directly, with no need to execute any code. Signature verification etc happens as part of the execution of the Ethereum system.


7

Whisper is not receiving funding from the Ethereum Foundation but is still being developed on by developers in their spare time. A new version 5 is reaching its final stage soon. If you're interested you can talk to developers on Gitter in the Whisper channel: https://gitter.im/ethereum/whisper. Swarm still is being developed and you can read more ...


7

Ethereum uses DevP2P, which is a general protocol of discovery and connection of nodes, with an ethereum subprotocol defined on top of it (as opposed to the subprotocol of swarm, whisper, etc). You can read the following links to get a deeper view: https://github.com/ethereum/devp2p/blob/master/rlpx.md https://github.com/ethereum/wiki/wiki/%C3%90%CE%9EVp2p-...


6

Ethereum does have transactions, which can be used to move Ether from account to account, but can also carry additional data as a payload, and trigger other actions on a smart contract (and could transmit zero Ether in the process). When spending Ether, you don't need to reference the exact input that is being spent in this transaction, only the account that ...


6

There are two primary ways that the existing PoW based consensus algorithm combats mining centralisation. The first is by reducing losses due to orphaned blocks, which independent miners are more likely to experience. This portion of the Ethereum mining algorithm, a technique referred to as GHOST, includes the headers only of recently orphaned blocks in ...


6

Yes and no. There's no way to enforce any given betting strategy in either PoS or PoW. For example, in PoW, there's no way to force miners to never mine on an attacker's chain. So, yes, a validator could be programmed to bet in any possible way. Betting doesn't quite work this way, however. There's been multiple versions of how betting works, what exactly ...


5

What were the technical challenges why the protocol didn't prevent them in the first place? There weren't any particular technical challenges. It was simply an oversight, "a mistake, a flaw in the protocol." This was a known subtlety (see "note: there is a difference between zero-balance and nonexistent") It was always understood that zero-balance ...


5

The determinism prevent any fork in the network. The same goes for Solidity which uses the EVM. To complete @NicolasMassart 's answer and @user1870400 comment that proposes to generate random values based on a possible Solidity implementation of the Go code used for random number generation, based on https://golang.org/src/math/rand/rng.go you can notice ...


5

The sending of a transaction from one Externally Owned Account (EOA) to another EOA does not involve the running of the EVM. Here are my results from my testing. I am running geth with admin.verbosity(6). Here are the debug logs from a transaction from one EOA to another EOA: > eth.sendTransaction({from: eth.accounts[0], to: eth.accounts[1], value: ...


5

There is precisely one validator with the right to create a block at any given height, randomly (but deterministically) chosen from the validators, weighted by their stakes. If that validator fails to do so, or their block is rejected by the rest of the network, then there is just a "hole" in the chain where that block would have been. This can happen ...


5

The project is still ongoing: https://github.com/ewasm/evm2wasm WASM seems more secure, also, webassembly is backed by Google, Apple and Microsoft, the community is also active, it's gonna be a widely used platform. So embrace WASM will be a really good choice. I'm also looking for the benchmark ...


5

The book named "Mastering Blockchain: Distributed ledger technology, decentralization, and smart contracts explained, 2nd Edition" by Imran Bashir, is what I believe to be the closest you'll find to a reference type of book on Blockchain (it talks a lot about Ethereum-related development) at given moment. However, Andreas Antonopoulos is working on a book ...


5

The method to extract the code eth.getcode takes an optional block height parameter as documented here. The function signature is: web3.eth.getCode(addressHexString [, defaultBlock] [, callback]), where defaultBlock (Maybe "block" would have been a better name?) can be any block number or some special valued strings such as "earliest", "latest", or "...


4

Possible answer: It is not entirely clear where Swarm and Whisper fit into the development roadmap and when or if they will be delivered by the same developers that developed the EVM... Source


4

In my opinion, we've already reached a point where there is no technical dependency on either of those things. In deference to convention, a lot of apps we see will choose to use such things for some time. To elaborate, an Ethereum node can bootstrap itself with nothing more than a clue about where it can find a peer. There are lots of ways to do that ...


3

What exactly are the problems in bitcoin's idea of blockchain that this new data structure is solving? Bitcoin itself uses Merkle trees (and therefore Merkle proofs) - it's not a new concept. Ethereum had to introduce something more complex - the Merkle Patricia tree - to store its state data. In short, state data is updated often, and this doesn't fit ...


3

When I tested a couple of weeks ago, whisper works inside the geth client, in that messages can be sent, and that messages can be received using filters. When I tried using the web3 client, which makes rpc calls to geth for similar functions, I found that sending messages worked, but creating filters failed (so I could not receive messages). No replies ...


3

The light client fetches all needed data from other nodes in the network. This means that if you request some data from your client that is does not have, it needs to pull it from the network. So it needs connectivity for that. If you request something it already has, then it will use that to reply. Intermittent connection is not a problem as long as you don'...


3

You are correct assuming you (and other nodes betting on block beta) have a higher security deposit than the consensus betting on block alpha. As long as honest nodes outnumber the dishonest nodes, the system will heavily favor honestly and discourage (by large penalties) dishonesty.


3

Yes - this came with snappy compression via EIP 706 (https://github.com/ethereum/EIPs/pull/706) - implementation in go-ethereum via https://github.com/ethereum/go-ethereum/pull/15106


3

I had to dig around to find the hint that I was pretty sure existed :-) It's in the Design Rationale document, under Compression algorithm. The wire protocol and the database both use a custom compression algorithm to store data. The algorithm can best be described as run-length-encoding zeroes and leaving other values as they are, with the ...


3

Smart contracts, to me, are the part of any distributed application (dApp) that runs on the blockchain's virtual machine. That could be Solidity code compiled down to EVM byte code, Vyper code compiled down to EVM byte code or straight out of the box hand-written EVM byte code. The dApp is, I think, bigger than that and includes the web3.js (RPC-based) user ...


2

Easiest place I know of is to look into the source code of sammy007/open-ethereum-pool. Here are the main JSON-RPC methods you will need to support, from sammy007/open-ethereum-pool/proxy/proxy.go, lines 232-269: switch req.Method { case "eth_getWork": reply, errReply := s.handleGetWorkRPC(cs) if errReply != nil { cs....


2

There's three reasons an attack like this wouldn't work (according to the current CASPER system.) First, there are no longer "contradictory" transactions. All a transaction needs to be valid is that it is properly formatted. Everything else, from nonce-checking to validating that the account has enough ETH to send, will be done by the EVM. So transaction X ...


Only top voted, non community-wiki answers of a minimum length are eligible