chronaeon / beigepaper Goto Github PK

Add this from the YP.

Do you think it could be good idea to start translating this document to Spanish? I could start doing the job and look forward who else would be interested in helping.

Lots of good feedback on the Tree diagram in section 2. People are saying they want to see more of that.

In section 3.7, The Ethereum Virtual Machine, the beigepaper states

The [EVM] memory stack has a maximum size of 1024-bits.

The yellow paper does not mention a unit, and the idea that the EVM stack is bound by literal bits doesn't make a lot of sense.

Rather, the EVM has a stack in which each item is a 256-bit word, and there may be a maximum of 1024 items in the stack.

Here's an additional source: https://www.ethervm.io/#stack

Section 2.1.1. Merkle Particia Trees states that

This allows the state data structure itself to represent not only the intrinsically correct paths in the data, but also the requisite cryptographic proofs which go into making sure that a piece of data was valid in the first place.

To me the highlighted part means that the modified tree allows for cryptographic proofs, implying that a non-modified tree would not allow this. If this was the intent, then in my opinion it is not true - any Merkle tree allows such proofs. This article from the official Ethereum wiki states that Merkle Patricia Trees were chosen because of optimization opportunities.

Firstly, thanks for this work! Such a comprehensive document has been long time missing resource. I'm greatly appreciative of the gaps it's filling in my understanding.

To the issue, 3.14.1 on Ethash, the end paragraph includes out of context text relating to contract engineering with a perhaps unmarked-up subtitle 'Implementing Contracts'

Implementing Contracts There are several patterns
of contracts engineering that allow particular useful
behaviours; two of these that I will briefly discuss are
data feeds and random numbers

I don't have time to review your paper, but I suggest you consider also making an audiobook so that people can learn about the EVM while they do other things.

Great job on the paper!

Small spelling mistake in the PDF beige paper, no biggie.

Pg 3
Paragraph 4
Sentence 2

'Indrexed' should possibly read 'Indexed'

Cheers

I have a colleague who is refuting this statement in your paper.

His main point of contention was that the world state is a couple hundred GB in size while a block is just several MB.

Just wanted to raise the issue and get your point of view.

Yellow paper says 20k for new storage, 5k to update storage and refund of 15k to clear storage. Has that changed?

Gas price is a value equal to the current limit of gas expenditure per block, according to the miners.

I don't know what that means and it sounds wrong. Isn't gas price specified in the transaction?

Bottom Left: Provisional state ... It contains three sets of data.

But nothing else - should list the three sets of data.

The Ethereum network is subservient to others in
terms of one thing only: ether, the native currency for
Ethereum.

Section 2.3.7. Transaction Receipts is empty. Is there a reason for that? Transaction receipts are described in section 4.3.1 of the Yellow Paper.

I will be happy to submit a PR with some content for this section if this is acceptable.

Yellow Paper is distributed under Creative Commons Attribution Share Alike 4.0, but Beige Paper is distributed under MIT License. Why did the licensing conditions change?

Really nice and interesting initiative, enjoyed reading so far! 😄 📖

The only criticism I have: maybe don't start with such a high version number v0.9.5 but with something lower - e.g. v0.7.0 and give this some time to evolve, with improvements from the community and generally some community building around it.

Then you can give this some more time to evolve towards a v1.0 release, which will stand stand on broader shoulders, being reviewed more closely and will generally have a better stance and being more respected in the community.

Thank you so much for this awesome work. This will greatly help me understand the yellow. I appreciate the time and effort that has been put into this document.

Related issue:
Page: 2 - Under 2.1.3. Recursive Length Prefixes. There is only step 1 in the document
"1. If the RLP-serialized byte-array contains a single byte integer value less than 128,
then the output is exactly equal to the input"
need to add the rest of the encoding logic as defined in the white paper
https://github.com/ethereum/wiki/wiki/RLP
for e.g:
2. "if the RLP-serialized byte-array contains a string... "

Many Thanks