This is more of a general question, but... what is the advantage of having a "faster" client, i.e., one that executes contracts faster? Is it just that your machine will use less power and you'll have a lower electricity bill? Or have more resources left over for computing hashes? Or is there an advantage to be gained from executing the contract faster than your peers?
Can anyone recommend a mid-level description of Ethereum that is more detailed than Wikipedia but not as detailed as the yellow paper? In particular, I'd like to understand whether mining fees are paid for executing contracts or for solving hashes or for both; and how consensus works (i.e., how it is coordinated that, as Wikipedia says, "[e]very contract is run on every full Ethereum node simultaneously and the result is the consensus of the output").
I think a greater benefit of using Rust is having a more secure client for something that handles transactions, contracts or money. Reliability, too, thanks to memory and concurrency protections. Some languages, maybe Rust, also have type systems and interface checks (eg Design-by-Contract) that can protect integrity of data by preventing it from being misused as well.
So, a number of benefits on correctness angle before one even considers speed.
In terms of performance and speediness, here are a few examples where faster means better:
* Overall, less time to wait as a normal user, e.g. when syncing with the network to verify transactions.
* Possibility to run the chain on low footprint iot devices.
* Mining is faster if transactions can be processed faster therefore more money – although admittedly the PoW itself dominates the cost here.
> In particular, I'd like to understand whether mining fees are paid for executing contracts or for solving hashes or for both
I believe the answer is both. Miners get a rewarded for finding a valid block of 5 ETH (typical PoW style reward) and they also receive the transactions fees paid by users of the network. And in Ethereum the cost of a transaction is determined by its 'gas' cost, which is based on how computationally expensive the transaction is.
> And in Ethereum the cost of a transaction is determined by its 'gas' cost, which is based on how computationally expensive the transaction is.
Right, but the gas cost cannot be distributed over _all_ nodes, I would think. Which is why I was wondering if it all goes to the node that is the first to announce that it has done a certain computation. Which leads me to wondering how "the first" is determined.
I'll keep looking around for more info, but I do hope Ethereum people realize that YouTube videos are not the same thing as proper documentation...
> Right, but the gas cost cannot be distributed over _all_ nodes
All computation on the Ethereum blockchain is done through the Ethereum Virtual Machine (EVM). The protocol defines a gas cost for each opcode in the EVM, hence the gas cost is distributed across all nodes.
Any singular node can change the gas cost in their client, but if they pay less than the cost that the miners expect then their transactions will not be processed - as it typical with distributed consensus systems.
> I'll keep looking around for more info, but I do hope Ethereum people realize that YouTube videos are not the same thing as proper documentation
> The protocol defines a gas cost for each opcode in the EVM, hence the gas cost is distributed across all nodes.
What I meant was this: Not every node that executes a contract can be paid for the gas. Some one node (or maybe a few) must "win" and get the gas cost. I was wondering which one it was.
Based on the White Paper (thanks for the link!) my rough understanding is now as follows: If a node executes a transaction and is the first to include that transaction in a block, then this node gets the transaction's gas cost plus a mining reward. Is this correct? Essentially, it would be like Bitcoin's transaction fees + block reward.
Each operation in the Ethereum Virtual Machine (EVM) has a cost defined by the protocol. Miners verify that each transaction has paid the necessary amount and any transaction that pays too little will not be included in a block.
These type of approaches are how to begin to SWAT proof privacy services analogous to what was Lavabit provided, but some of other issues are:
- overlay node discovery, registration (which ethereum may handle)
- interop with common protocols DNS/TLS/SMTP/IMAP/IP/"entry|exit" nodes
- assure high availability of persistent data
- end-to-end encryption
- incentivize people to run nodes to provide bandwidth, low latency, storage and computing resources... possibly to rate limit the API and pay/barter nodes with multiple cryptocurrency/ies ( LTC / maaaybe something on top of ethereum in addition to BTC)... more than just for access, but analogous to running a solar array at home and being connected to the grid
- ease of building applications and extensions on top of other distributed services (make it dead simple, not over-engineered... ethereum appears to do this)
For those wondering why the title says this is implemented in rust, despite the page not mentioning it, it says on the homepage that Parity is implemented in rust.
did anyone get this working? I have been trying to get either eth or this client working for some time with no luck. It's failing for me (parity) when I run `cargo run --release`, permissions problems. Haven't had more time to debug.
There is a gitter channel https://gitter.im/ethcore/parity
Please get in touch with my colleagues there so they can help you getting parity up and running.
Can anyone recommend a mid-level description of Ethereum that is more detailed than Wikipedia but not as detailed as the yellow paper? In particular, I'd like to understand whether mining fees are paid for executing contracts or for solving hashes or for both; and how consensus works (i.e., how it is coordinated that, as Wikipedia says, "[e]very contract is run on every full Ethereum node simultaneously and the result is the consensus of the output").