Questions: block-finalisation state transition function: Ω definition

[WhisperingChaos]

I've some questions regarding my understanding of the paper's notation and wasn't sure where to post them. Therefore, let me know if there's a better forum to direct my questions.

The paper begins with the following: (1) σ_t+1 ≡ Υ(σ_t, T) where σ_t represents the current canonical state (version) of the Ethereum World and T represents a transaction to be applied to this state. Once applied by Y, T yields a new World state.

Soon after defining the above, the paper describes block-finalization by (2) σ_t+1 ≡ Π(σ_t, B) Since B is substituted for T, the above represents B as a Transaction. (3) B ≡ (...,(T₀, T₁, ...)) This defines B as containing components some being transactions: (T₀, T₁, ...) while other components "...," aren't defined. I believe this definition casts B as an aggregate Transaction.

(4) Π(σ, B) ≡ Ω(B, Υ(Υ(σ, T₀), T₁)...) In this equation, B on the right hand side becomes σ_t suggesting B represents the current canonical state (version) of the Ethereum World. While its aggregated transactions Υ(Υ(σ, T₀), T₁)... are substituted for T.

So here are my questions:

• In (4) above, B presents a duality: it seems both an aggregate Transaction and the current canonical state (version) σ_t of Ethereum. Is this true?
• When applying Υ(Υ(σ, T₀), T₁)...) the answer is σ_t where _t represents number of transactions in B. Therefore, rewriting (4) generates: Π(σ, B) ≡ Ω(B, σ_t) Does (4) violate (1) where B should represent σ_t and σ_t should represent a Transaction?

Perhaps (4) could be written as:

(4) Π(σ_t, B) ≡ Ω( Y_n(... (Υ₁(Υ₀(σ_t=0, T_t=0), T_t=1) ,... ) ,T_t=n) ,R)

Where R represents the rewards Transaction issued to a nominated party.

Thanks for any insight you can offer.

[chronaeon]

Great points, glad to see someone else brought this up. Similar to my remarks in: https://github.com/ethereum/yellowpaper/issues/457.

[jamesray1]

@WhisperingChaos, yes, a block aggregates transactions, represents the state of Ethereum 1.0 at a point in time, like a message in a ledger, where this message is then gossiped amongst validators and miners (in a peer to peer network) until it is accepted into the GHOST, the greediest, heaviest observed subtree, or rejected if not.

[jamesray1]

For the second question, I don't think there is a violation, but it isn't very clear, and it could be rewritten as you propose. Would you like to make a pull request?