https://docs.google.com/document/d/1ErnINROrH3KiMei_jGr6Xwcg0rGb9kd1NUICU7Rky7c/edit#

Can someone DM Artem this call link? His permissions dont allow me and want to avoid public posting and zoom bombers

hahaha

That's bad for offline clients... How would I generate all the required block witness if I was offline for 4 periods?

Isn’t 1 period ~1yr?

Yeah, we just don't have any of the tooling to address my question...

+1 Rick. Say people only checking some accounts from 2017 now…

I think if we just make sure the block witness generation service exists, it's fine.

I'm building a service that could do this.

I think it's fine as a mechanism if we assume the other tooling will exist, but it should be stated explicitly that other tooling is needed.

+1 on stating assumptions about add’l service(s)/tooling needed

I actually think the proposal and its related writeups are fairly explicit about responsibility for state going over to users for state older than 2 periods

Yeah, the reality is users will rely on a service.

FYI ipsilon is the new name of the ewasm team, in case anyone is wondering :)

ah, I was indeed wondering exactly about that :-)

good to know1

whoa when did you guys get this name?

started to use publicly a month ago, but renaming was planned for a very long time

congrats :)

🙌

also, the first period would not have to be 1 year - so this last hart fork could happen only once all the tooling is in place

https://github.com/ethereum-cdap/cohort-zero/issues/62

Thanks for inviting me. This seems pretty good.

I think this is awesome btw - having a couple of very cheap sload locations would be great for many dapps

DELEGATECALL style smart contract decomposition becomes potentially viable in this model while still being gas efficient

Bad news is that cureent proxy contracts

That current proxy contracts do not work with this

why not? don’t they use storage slot 0 by default for storing their target address?

no :)

oh, wasn’t aware

Hard to type on phone, but the conversation can be found on the #evm channel on 2nd june

Proxies use a hash for the slot to avoid storage collisions with regular contract variables

ah right, makes sense

Only basic storage variables benefit from being in the main tree, so like owner mostly

and arrays/bytes/string (in solidity terms) benefit from the adjacent property

Should state expiry EIP, at least the period2 hard fork, be dependent on an EIP for a truly decentralized block witness service/tooling and it running in production for some time? (Or will most people be putting trust in Rick's service? ;) )

Suppose I send a transaction, but after I send the transaction the state changes so my transaction requires a resurrection that I didn't include, what happens?

The verkle tree EIP is not dependent on the address space change as long as it just pads current addresses, as stated in the doc. Can the verkle tree implementation/experimentayion kick off already? It seems to make sense even if expiry does not materialises.

Unified and balanced trie will also allow portal network state management to be get significantly more efficient, both in how it is stored by individual nodes, and in reducing access from being something like O(average-depth-of-the-trie) to be ~O(1) for each piece of information accessed.

Why little endian?

Similarly, once tries become frozen, a more "torrent" style seeding of cold state also becomes possible since the cold state data no longer changes.

@axic I think the case for starting Verkle tree prototyping separately now already is strong (and Guillaume has already done some work there I think!). That’s a benefit of this modular approach, that we then can have separate prototyping of address extension and then finally full state expiry

Assuming the answer to my question is "it just fails", do we need to investigate how bad a problem this is?

@Peter, I think you are correct that it would fail - this is a good example of what we called Dynamic State Access back in the execution environment context. basically, applications with DSA patterns would indeed become more fragile once they get dropped out of active state

Can the name "address space" be changed to "address period"? The "address space" has different meaning to me and is very confusing in this context.

@Joseph I think this is a tradeoff we have to make at some point (how much tooling do we want to wait for). I personally am weakly in favor of moving quicker and alleviating strain on full nodes as soon as we can, and really hold users ultimately responsible for expired state. Although my guess is that sufficient tooling would be in place anyway by the time the phase 0 tree expires.

We should add investigation to using a precompile to retain support for legacy transaction types.

Can you send new tx type from the old (short) address?

I think there would be an automatic conversion of old addresses to the new address type under the extension proposals

What is the reason to allow creating addresses in various spaces? In our overview we argued to not introduce create3.

I think the idea is to allow for old contracts to access the most recent space

But to keep the address space of the caller.

Not sure how it allows that?

same day and time next week?

ah wait, I worded that somewhat wrong. I think the idea is rather to have child contracts in the most recent address space

continue the conversation and questions/discussion in the #state-expiry channel

because being in the most recent one makes access to previously unset storage locations cheaper (not requiring non-inclusion witnesses)

so this is kind of a must-have to allow for contracts to be efficiently usable over multiple periods

@ansgar we were wondering to solve incentives for migration instead of complicating cross creation

No answers yet :)

I could definitely see that being a viable alternative approach

Thanks for organizing Robert and thanks v

c ya