herrbez / ethereum-scalability Goto Github PK

I would like to add some few lines to introduce the application layer of Ethereum, so that it does not looks ugly ^^ and also why all other layers have a brief introduction

I know, that I have written this part ^^, but I think that points 2 already include points 3.
In addition the nodes should verify the whole block header and not only the nonce, e.g. they should verify that the gas limit is contained in the range

Moreover, we use an enumeration, but the order is surely, different. I think that my client would previously check the block header and also the nonce and only after may think to compute the transactions

My Proposal

There are two types of accounts:

• Externally Owned Account (EOA) (referred to also simply as accounts)
• contract account (referred to also simply as contract

Decide and apply when to write a word with bold, italic or texttt.

Here is my proposal:

bold

I think that one could completely avoid bold font, but in our case, it should be fine (I like it), but we have to use it only for extremely important words

italic

When new (unconventional) words are introduced for the first time.

code

For packet-types (e.g., Ping, Pong) and program names (e.g. geth)?

Any comments/suggestions?

Add description of what is a dapp and why it is not or is decentralized in an Appendix (Because it is not part of the Ethereum Core, but includes also external services)

RLPx distinguish between node discovery and propagation protocol

Should we mentione/describe the JSON RPC?

Kademlia description is very similar to the one of the original paper (section 2.2)

Add in the introduction a brief terminology paragraph, in which we say that for geth we intend go-ethereum implemnetation\footnote{url to go ethereum} and for hash we intend always the keccak256...

Add "accessed" to all urls in bibliography + Add "ethereum foundation" as author of the wiki entries

Find a location for Proof of Stake paragraph

It would be better to define one per all at the beginning of the report, that we use "go-ethereum" abbreviated as geth as a reference implementation.

Currently, we repeat this fact a lot of time in the test and added the urls more than once.

https://media.readthedocs.org/pdf/solidity/develop/solidity.pdf

Although there is a common agreement on the ABI format, this abstraction is not part
of the core Ethereum protocol meaning that anyone can define and expose its own ABI,
but the caller have to comply to the format used by the callee.

I would add the reference to the solidity docs (it has a chapter about the specification)

A contract may call another contract through a message call.

In addition, I am not sure if it is correct to talk about a message call when returning the result of the execution. According to the yellow paper the result is the output of a message call

In my opinion, it is of fundamental importance to describe more accurately the World State and its component. This makes it clear that this system is very difficult to scale and prone to centralization because the world state is a big piece of data.

Shall we change the section title?
W.r.t. the content, now we cite two references but I think we should close the section saying something like "The scalability matters"

The x-axis of the cube of the scalability is concerned with the horizontal duplication
and cloning of services and data with absolutely no bias, running each identical copy of
the system on a different server. Usually, the work is distributed by a load balancer.

It is necessary that the identical copies are run on different servers?

Decide whether to include the description of different node types or not.

In case we discuss the light nodes, I will suggest to add a section about the LES subprotocol.

Maybe in the Appendix we could add a little description

Both should review each chapter, before the submission:

Giacomo

• Introduction
• Architecture
  • Network Layer
  • Propagation Layer
  • Data Layer
  • Consensus Layer
  • Application Layer
  • External Interaction
• Scalability
  • To Scale or not to Scale
  • Background
  • X-Axis
  • Y-Axis
  • Z-Axis
  • Tests
• Conclusion
• Solidity
• Node types

Mirko

• Introduction
• Architecture
  • Network Layer
  • Propagation Layer
  • Data Layer
  • Consensus Layer
  • Application Layer
  • External Interaction
• Scalability
  • To Scale or not to Scale
  • Background
  • X-Axis
  • Y-Axis
  • Z-Axis
  • Tests
• Conclusion
• Solidity
• Node types

Describe ethereum consensus protocol and proof of work...

Since we use Solidity, would be good to write something about the language. Maybe the appendix is a good place for it.

Add a general introduction, that should cover these arguments:

• Motivation
• General Introduction to blockchain
• Bitcoin?
• ... Add other fields

I think that Appendix B (Node types) should be put before Appendix A (Solidity), because the former occurs previously in the text and is more concerning the rest of the work.

It is only a proposal

Divide consensus layer into multiple subsubsections:

• PoW
• GHOST
• Mining
• Transaction Execution

Describe the ethereum virtual machine

Fix Scalability introduction to be coherent with the rest of the Section.
Do this, once we have already closed:

1. #35
2. #36 and #38
3. Eventually #24

I know that the data are stored with RLP protocol. But how is the merkle patricia tree stored? And the key value pair lookup how does it really work?

Maybe it's late, but we talked about openness of the system w.r.t. the new entering nodes. What to do with this?

I don't like this definition of receipts provided in the data layer

In [15], Vitalik Buterin 18 writes that with the receipt information, someone can answer queries like “Tell me all instances of an event of type X (e.g. a crowdfunding contract reaching its goal) emitted by this address in the past 30 days”.

#40

Can we provide a better description?

I make a branch in which I try to fix the size of the images about the execution, so that we do not have entire pages with only an image, which I don't like.

We could add some figures representing the protocols (or better, the interactions between them, someway), something like this. Useful to break the reading.

Close all branches and inspect existing ones, eventually perform PRs.

I think the three sections talking about the axes should be moved up by one level, and subsequently the child sections. This way it is clearer what is discussed in them.

Add some details about the Ethereum Virtual Machine call stack

Eventually, add some reference to the formal specification of the EVM by the TU Wien.

Complete the section about the p2p communication, the overlay network and the dissemination of the information.

Descibe blocks in the architecture?

Should we add a conclusion in which we briefly summarize the results of the report?

Talking about the Network Layer, we should separate more Kademlia description from RLPx Node Discovery description.

Maybe related to #16

Should we also add additional information about the results?

1. Currently, we report only the average throughput. I think that is interesting the maximal value that we can reach.

2. The average number of transaction inside a block with the different gas limits

3. The size of the state/blockchain (If I find the results, or simply the value that we can find in some sources)

• Add description of test configuration
• Make a first study with a fixed number of nodes and by testing with different number of miners
• Make a graph that correlates the number of nodes and throughput with different number of nodes
• Make a graph that correlates time and size of blockchain

In my opinion, it is always a drawback, because of consistency problems etc. So I would change in:

This could seem not a drawback at first, but it becomes unmanageable if the data size increase

Or something similar