AllCoreDevs - Consensus #184

Should be a fun call lol 😅

Reacted to "Should be a fun call lol 😅" with 🤘

Hey all

Reacted to "Should be a fun call lol 😅" with 🤘

Reacted to "Hey all" with ❤️

Replying to "Should be a fun call lol 😅" they always are

Reacted to "Hey all" with ❤️

gm

Gm

Reacted to "Hey all" with ❤️

gm

gm

Reacted to "Gm" with 👋

gm

gmgm

gm

Gm

gm

https://github.com/ethereum/beacon-APIs/pull/630

wen devnet-8?

Good day everyone

Iryna is using Circleback (https://circleback.ai) to record and generate AI meeting notes for this meeting.

any cl devs implemented this?

would be good to get a signal

Today’s agenda btw: https://github.com/ethereum/pm/issues/2177

Aarsh has been working with Bosul on prysm.

Everything looks good so far, we are positive on it.

its already in the scope for devnet 8

(brb)

on CL side it is rather straighfoward

Reacted to "on CL side it is rather straighfoward" with 👍

Replying to "https://github.com/e..." In the CL breakout of ACDT this week, I believe we agreed to hold off on merging this until there were more prototypes.

https://notes.ethereum.org/@ethpandaops/glamsterdam-devnet-8

so you can provide images for clients for public usage right?

Reacted to "so you can provide images for clients for public usage right?" with 👍

Replying to "so you can provide i..." Yup, we’ll have pandaops images

Replying to "so you can provide i..." that's awesome ty!

`--network plataberget` on every client ideally

Reacted to "`--network plataberget` on every client ideally" with 👍

--network polarbear

Reacted to "`--network plataberget` on every client ideally" with 👍

Reacted to "--network polarbear" with 😂

Reacted to "`--network plataberget` on every client ideally" with 👍

Reacted to "--network polarbear" with 😂

Reacted to "--network polarbear" with 🤘

Reacted to "--network polarbear" with 😂

Reacted to "--network polarbear" with 😂

Reacted to "`--network plataberget` on every client ideally" with 👍

Reacted to "--network polarbear" with 😂

Reacted to "In the CL breakout o..." with 👍

Where is the exact genesis date written down for Plataberget?

https://github.com/ethereum/EIPs/pull/12063

Replying to "Where is the exact g..." its still ETA

Reacted to "its still ETA" with 👍

Replying to "Where is the exact g..." We will finalize the date hopefully on ACDT

Reacted to "https://github.com/ethereum/EIPs/pull/12063" with 👍

Replying to "Where is the exact g..." Ah I thought you said “next week”.

Replying to "Where is the exact g..." (For the launch)

could we again do per-client attestation sorting?

Replying to "Where is the exact g..." yes we wanna launch next week

Replying to "Where is the exact g..." but we also wanna make sure we don’t launch if half the clients are not ready

Replying to "could we again do pe..." doesn’t really account for multi-node setups either

Antwoord verzenden naar "(brb)" back

Replying to "could we again do per-client attestation sorting?" true, good point

https://github.com/eth2353/EIP-8359

Replying to "Where is the exact g..." If we want to launch with a special testnet flag in a release, we need lead time for testing. But we can always just use a fork config file at genesis.

I will go over it as well this week

Replying to "Where is the exact g..." Yeah its not essential to have a client release out before launch time

Reacted to "Yeah its not essential to have a client release out before launch time" with 👍

Graffiti data for the few past months: https://clients-diversity.nalepa.org/

Replying to "Where is the exact g..." we just ideally wanna have a client release out by the time we hit gloas which will be a week after genesis

Reacted to "we just ideally wanna have a client release out by the time we hit gloas which will be a week after genesis" with 👍

Have proposed a fix for the CI blocker, if you add that we can merge :)

https://eips.ethereum.org/EIPS/eip-8198

Antwoord verzenden naar "Have proposed a fi..." @hanniabu

Reacted to "https://eips.ethereum.org/EIPS/eip-8198" with 🎉

Reacted to "https://eips.ethereu..." with 🎉

Reacted to "https://eips.ethereu..." with 🎉

Replying to "https://eips.ethereu..." this eip describes 8s btw

Reacted to "https://eips.ether..." with 🎉

Replying to "Where is the exact g..." Why are you looking to have releases for this devnet btw?

Replying to "https://eips.ethereu..." good point, should be updated. 8s was the original idea, now a stretch goal

Replying to "https://eips.ethereu..." I’d say it’s all pending testing

Reacted to "I’d say it’s all pending testing" with 👍

Not seeing this in the survey. Have we evaluated the geographic centralization pressure from shorter slots?

Reacted to "Not seeing this in the survey. Have we evaluated the geographic centralization pressure from shorter slots?" with ➕

Reacted to "Not seeing this in t..." with 👀

Reacted to "Not seeing this in..." with 👀

Reacted to "Not seeing this in..." with 👀

Reacted to "Graffiti data for the few past months: https://clients-diversity.nalepa.org/" with ❤️

Reacted to "Not seeing this in the survey. Have we evaluated the geographic centralization pressure from shorter slots?" with 👀

My main concerns with variable slot time would be breaking existing contracts, if any large contract has hardcoded the fix 12s slot time as an assumed constant, it would break user land. I see that its an ongoing identification, but I wanna make sure we don’t break any significant deployed contract.

Replying to "Not seeing this in t..." It’s a good question. I think I saw a network wide latency analysis a while ago, worth looking into more!

"continuous" decreases in slot time create, arguably, more create more disruption than figuring somewhat larger jumps. it's true both that the main issue is variable slot times at all, but also, all these infra assuptions etc etc have to be re-evaluated separately each decrease

Reacted to "Not seeing this in t..." with ➕

Replying to "My main concerns wit..." We have this assumption in Lido. But we are ready to upgrade to the version that removes this assumption

Replying to "Not seeing this in t..." 10s shouldn’t change the pressure that much imo

Replying to "My main concerns wit..." Arbitrum has this assumption for the challenge period length but they can just upgrade and fix it

I'd say that we'd need to reach out to defi protocols that have fixed maturity times that rely on 12 second slots to calculate when their bonds mature (e.g. pendle)

Reacted to "10s shouldn’t change the pressure that much imo" with 👍

the more changes in slot time, the more nonlinearities, the more boundary conditions, the more special cases. There won't be that many of these, potentially, before more fundamental redesigns are required. .so adding lots of small changes has its own csts

Say with 10-second slots, would we keep the same gas limit and blob limits? Or try to scale them, eg (10/12) * gas_limit.

Replying to "Say with 10-second s..." Pls no

Reacted to "We have this assum..." with 👍

Replying to "Not seeing this in t..." Happy to ask lido curated NOs to help out here if it would help, however any test not on mainnet is difficult to reason about (because PBS plays a big role and there’s nothing like mainnet)

Replying to "My main concerns with variable slot time would be breaking existing contracts, if any large contract has hardcoded the fix 12s slot time as an assumed constant, it would break user land. I see that its an ongoing identification, but I wanna make sure we don’t break any significant deployed contract." this wasn't really possible before we put the slot number in blocks. Until then you could only have certainty that something is after some timestamp, or you would have used 4788 to prove against the beacon root - not sure any contract ever did that

Replying to "Say with 10-second s..." The EIP mentions that at fork boundary the gas limit is scaled

Replying to "My main concerns wit..." Contracts should switch to using slot number opcode

Reacted to "10s shouldn’t change the pressure that much imo" with 👍

Replying to "Not seeing this in t..." yes my assumption would be that it would be more a consideration further down the road, limiting how far we can responsibly go with slot times

Replying to "Say with 10-second s..." Ah okay thanks

Reacted to "Arbitrum has this assumption for the challenge period length but they can just upgrade and fix it" with ➕

Reacted to "yes my assumption would be that it would be more a consideration further down the road, limiting how far we can responsibly go with slot times" with 👍

Reacted to "Happy to ask lido curated NOs to help out here if it would help, however any test not on mainnet is difficult to reason about (because PBS plays a big role and there’s nothing like mainnet)" with 👍

Replying to "Not seeing this in t..." but something to watch for. a bucnh of NOs run in africa and latam and report some issues as it is

Reacted to "yes my assumption would be that it would be more a consideration further down the road, limiting how far we can responsibly go with slot times" with 👍

Replying to "Not seeing this in t..." Yep, those would be the best to pull into this

Replying to "Say with 10-second s..." I feel like it would be a nice scaling goal to aim to keep the same gas limit and blob limit values for H* if we do end up doing lower slots

Replying to "Not seeing this in t..." should be used like a canary

Just a 12 -> 10 speed up is worth the hastle?

Reacted to "We have this assumption in Lido. But we are ready to upgrade to the version that removes this assumption" with 👍

Reacted to "Pls no" with 👍

Replying to "Say with 10-second s..." Scaling down gas limit per block is also odd. It may break existing work flow

Replying to "Say with 10-second..." gas limits this should be done intentionally

Replying to "Say with 10-second s..." no the idea would be that the throughput per second would remain the same, or even go down, when slot times are reduced

Replying to "Just a 12 -> 10 sp..." It is the first step towards even shorter ones in future ?

Replying to "Just a 12 -> 10 spee..." possibly, to make future changes much easier? gets the bugs out of slot timing code

so the per-slot throughput would definitely go down

Reacted to "no the idea would ..." with 👍

Reacted to "but something to wat..." with 👀

Reacted to "Just a 12 -> 10 speed up is worth the hastle?" with ➕

Reacted to "It is the first st..." with 👍

Replying to "Say with 10-second slots, would we keep the same gas limit and blob limits? Or try to scale them, eg (10/12) * gas_limit." scaling down shouldn't break things as we have a tx gas limit that is already below the block gas limit

Replying to "Say with 10-second s..." Right so per block will go down. Question is what that breaks. Atomic bundle requiring more than X gas can no longer fit in one block

Replying to "Graffiti data for th..." Updated to Lodestar 1.45.0 to add my 5 cents

Replying to "Just a 12 -> 10 spee..." Constant changes are not great for users and consumers

Reacted to "Graffiti data for the few past months: https://clients-diversity.nalepa.org/" with ❤️

Replying to "Not seeing this in t..." Do you have any write up on issues they encounter by chance?

Reacted to "gas limits this should be done intentionally" with 👍🏼

Replying to "Where is the exact g..." Ease of use for users

Replying to "Say with 10-second s..." well lucklily this comes at a time where overall gas limit is going up a lot

Replying to "Say with 10-second slots, would we keep the same gas limit and blob limits? Or try to scale them, eg (10/12) * gas_limit." but those bundles are not possible today. They would only be at 300M gas limit and we then go down a bit

Replying to "Just a 12 -> 10 sp..." But you need to start from somewhere ow you never improve over 12secs

Replying to "Where is the exact g..." A branch is fine imo. Don’t need a release

Replying to "Where is the exact g..." otherwise they will have to use a custom genesis.ssz

12 to 10 is almost 20% better

Reacted to "12 to 10 is almost 20% better" with 👍

Replying to "Where is the exact g..." Prysm can do a pre release if you want. We don’t need a formal release over this

Replying to "Where is the exact g..." A branch is always prone to become stale

@Dustin want to go faster?

Reacted to "12 to 10 is almost 2..." with 😁

Replying to "Just a 12 -> 10 sp..." and then allows for easiesr future improvements

Replying to "@Dustin want to go..." if done at all yes

Reacted to "But you need to start from somewhere ow you never improve over 12secs" with 💯

Replying to "Where is the exact g..." Ideally whatever this is gonna be, will be getting updates down the line and can test till we hit mainnet

Reacted to "It is the first step..." with 👍

Reacted to "and then allows for easiesr future improvements" with ❤️

I think it’s clear at this point that a very large jump (say down to 6s) will not have room in a hard fork any time soon, maybe not before 2030. so I’d rather get to 8 (or 6) incrementally over several forks, rather than sticking with 12s for 5 more years

Nothing written up, just more missed proposals than others (and sometimes even issues with attestation timing and/or head votes) and especially when it comes to PBS stuff (it’s since drastically been improved since we onboarded African and LATAM operators 2 years ago, but it took a lot of work on their side from infra improvement perspective)

Reacted to "It is the first step towards even shorter ones in future ?" with 👍

Replying to "Just a 12 -> 10 spee..." Our testing should be good enough to deploy things in main net that work. The only justification to go moderate is to give slack for ZK to catchup

Replying to "Say with 10-second s..." Hm ok. If you guys say that decreasing max gas limit / block doesn’t break anything then I trust y’all

Replying to "Not seeing this in t..." Do you have any write up on issues they encounter by chance? don’t have a write up, but the quick answer is far away nodes get blocks late, and thus get incorrect head more often than near nodes. Head vote accuracy is ~20% of a validators rewards, so its already very punitive to be in this position. (maybe ePBS makes this less bad, its mev timing games that are particularly causing this, rather than when proposals are honestly broadcasted at t=0)

Reacted to "I think it’s clea..." with 💯

Reacted to "But you need to start from somewhere ow you never improve over 12secs" with 👍

Do we have more information on what big contracts (if any) are reliant on the hard coded 12 seconds number from the sourcify survey?

Reacted to "I think it’s clea..." with 💯

Reacted to "Not seeing this in the survey. Have we evaluated the geographic centralization pressure from shorter slots?" with 👀

Reacted to "10s shouldn’t change the pressure that much imo" with 👍

Reacted to "Happy to ask lido curated NOs to help out here if it would help, however any test not on mainnet is difficult to reason about (because PBS plays a big role and there’s nothing like mainnet)" with 👍

Reacted to "Hm ok. If you guys say that decreasing max gas limit / block doesn’t break anything then I trust y’all" with ❤️

Reacted to "Do we have more in..." with 👀

Reacted to "Do you have any writ..." with 👍

Reacted to "Nothing written up, ..." with 👍

Reacted to "Do you have any writ..." with 🙏

Reacted to "Do you have any write up on issues they encounter by chance? don’t have a write up, but the quick answer is far away nodes get blocks late, and thus get incorrect head more often than near nodes. Head vote accuracy is ~20% of a validators rewards, so its already very punitive to be in this position. (maybe ePBS makes this less bad, its mev timing games that are particularly causing this, rather than when proposals are honestly broadcasted at t=0)" with 👍

Replying to "Just a 12 -> 10 sp..." This EIP opens the space that "whenever we have slack, we improve slot time", so that's nice imo

Reacted to "This EIP opens the space that "whenever we have slack, we improve slot time", so that's nice imo" with 👍

One could prove the slot number against the EIP-4788 beacon block root. Something to also consider when analysing backward compatability

Reacted to "This EIP opens the space that "whenever we have slack, we improve slot time", so that's nice imo" with 👍

Reacted to "Constant changes a..." with 👍

Reacted to "Just a 12 -> 10 sp..." with 👍

Replying to "Not seeing this in t..." Very interesting, thanks!

Reacted to "This EIP opens the space that "whenever we have slack, we improve slot time", so that's nice imo" with 👍

Reacted to "but something to wat..." with 👍

Reacted to "Do you have any write up on issues they encounter by chance? don’t have a write up, but the quick answer is far away nodes get blocks late, and thus get incorrect head more often than near nodes. Head vote accuracy is ~20% of a validators rewards, so its already very punitive to be in this position. (maybe ePBS makes this less bad, its mev timing games that are particularly causing this, rather than when proposals are honestly broadcasted at t=0)" with 👍

Reacted to "Nothing written up, ..." with 🙏

Replying to "Not seeing this in t..." which also means that we have some (unclear) leeway in block times here - mev timing games will adapt

Reacted to "Nothing written up, ..." with 👍

https://github.com/ethereum/EIPs/pull/12110

Reacted to "Do you have any writ..." with 👍

Replying to "One could prove the ..." it’s a major pain tho

Replying to "One could prove the slot number against the EIP-4788 beacon block root. Something to also consider when analysing backward compatability" agree but maybe it happened

Reacted to "it’s a major pain tho" with 💯

Replying to "One could prove the slot number against the EIP-4788 beacon block root. Something to also consider when analysing backward compatability" ah, you mean finding out if it happened is the painful part?

Reacted to "it’s a major pain tho" with 💯

Replying to "One could prove the slot number against the EIP-4788 beacon block root. Something to also consider when analysing backward compatability" I'm bringing this up not to propose something for apps. It's because before we ship SLOTNUM in glamsterdam, this was the probably best way to prove exact time on the EL

https://github.com/ethereum/EIPs/pull/12072

Replying to "One could prove the ..." ah right got it I think it didn’t happen

Reacted to "it’s a major pain..." with 💯

Will this be sending payloads in columns? That probably won’t work with ePBS

Replying to "One could prove th..." also I don't think we actually want to encourage people to start hardcoding zk-proofs against blocks or state quite yet better to wait until new state tree, everything ssz, and ethereum's long-term hash function (looks like blake is leading now) gets finalized otherwise those upgrades become harder on dapp devs

regarding 8142: could we please finish shipping partial cells and sparse blobpools before we try to introduce yet another design change? Currently we don’t seem to be the place where we need infinite blob growth, so I’d rather we focus on finishing the open topics, before we CFI a new idea.

Reacted to "This EIP opens the..." with 👍

How are payload blobs reflected in blob_gas_used and excess_blob_gas?

Replying to "Will this be sending..." How would the PTC vote?

Replying to "One could prove the ..." we could consider having a precompile that exposes some of these parameters, like take an index for which info you want (plus maybe a slot number if we want historical data to be accessible), return slot time, maybe also blob parameters, etc

Reacted to "How are payload blobs reflected in blob_gas_used and excess_blob_gas?" with ➕

A branch is always prone to become stale Confusing to state as an advantage over a branch because a release is frozen in time, so it’s always “stale” by definition.

Reacted to "also I don't think we actually want to encourage people to start hardcoding zk-proofs against blocks or state quite yet better to wait until new state tree, everything ssz, and ethereum's long-term hash function (looks like blake is leading now) gets finalized otherwise those upgrades become harder on dapp devs" with 💯

Replying to "One could prove the ..." could also make it a system contract that stores these parameters in storage and updates them on each hard fork, so that we don’t have to special case access to this information in proofs

Reacted to "This EIP opens the space that "whenever we have slack, we improve slot time", so that's nice imo" with 👍

Replying to "Where is the exact g..." well I assume that you make the release off of your trunk branch. Which is a good indication that the code thats out for this named testnet is very close to the same to what you gonna have for mainnet.

Reacted to "could also make it a system contract that stores these parameters in storage and updates them on each hard fork, so that we don’t have to special case access to this information in proofs" with 👍

Reacted to "I think it’s clear at this point that a very large jump (say down to 6s) will not have room in a hard fork any time soon, maybe not before 2030. so I’d rather get to 8 (or 6) incrementally over several forks, rather than sticking with 12s for 5 more years" with 💯

Reacted to "12 to 10 is almost 20% better" with 👍

Feels cleaner to keep payload and type-3 blobs separate

Replying to "One could prove th..." maybe next step post-PBT is to just unify state tree structure and SSZ so CL state and even the hashing of a block is all done through the same mechanism ("for any nontrivial sized object, hash it by defining a schama that turns it into a key/value store and then make the PBT root of it) such things would take longer than H* though

Replying to "I'd say that we'd ne..." @jonny if some come to mind and you are happy to intro, let me know! would be very useful

Reacted to "could also make it a system contract that stores these parameters in storage and updates them on each hard fork, so that we don’t have to special case access to this information in proofs" with 👍

Yeah I don’t see how this works, why not just erasure code the payload itself

Replying to "https://eips.ethereu..." yes this is my bad, I meant to update the EIP and offer a PR to quickslots.info to reflect the 10s anchor target so consider those two outdated currently, pending an update

Either RS or RLNC just for the payload

Reacted to "Feels cleaner to k..." with 👍

https://github.com/ethereum/EIPs/pull/12118

Replying to "Either RS or RLNC ju..." Ya that would be faster

Replying to "Feels cleaner to keep payload and type-3 blobs separate" cc @Kamil Salakhiev

Replying to "Either RS or RLNC ju..." This has even already a POC

Reacted to "but something to w..." with 👍

the main cost of reconstructing is still the proofs

like almost 99% of of it

Reacted to "like almost 99% of of it" with 👍

Reacted to "maybe next step post-PBT is to just unify state tree structure and SSZ so CL state and even the hashing of a block is all done through the same mechanism ("for any nontrivial sized object, hash it by defining a schama that turns it into a key/value store and then make the PBT root of it) such things would take longer than H* though" with 👍

Reacted to "like almost 99% of..." with 👍

Replying to "I'd say that we'd ne..." ya I'll see if I have a contact, but I think Charles St Louis (EF) would be a good place to start. I'll ping him and ask him. qq, when you were scanning contracts for reliance on 12 second slots, how did you do that? did you look for contracts that have logic dependant on block number?

Replying to "Feels cleaner to kee..." how exactly? they have same DA requirements and from networking perspective these are the same kind of objects, so reusing existing columns seems natural for me

Replying to "like almost 99% of o..." I imagine a DataRowSidecar would also contain proofs.

https://github.com/ethereum/EIPs/pull/12081

https://docs.google.com/presentation/d/1BBlYjhzVibXTigHKhrOk59PvFG9AmdVhFKsf-MTN8WM/edit?usp=sharing

3 mins for the talk. 27 mins for the spice

Replying to "Either RS or RLNC ju..." I think you probably want to bolt on kzg, signatures or some other cell authentication scheme. Then the payload topic operates very much like a blob column topic with cell level deltas

Reacted to "3 mins for the talk. 27 mins for the spice" with 😅

Reacted to "3 mins for the talk. 27 mins for the spice" with 😅

A réagi à "3 mins for the tal..." avec 😅

Reacted to "3 mins for the talk. 27 mins for the spice" with 😅

Reacted to "3 mins for the talk...." with 😅

Reacted to "3 mins for the talk. 27 mins for the spice" with 😅

Reacted to "3 mins for the talk. 27 mins for the spice" with 😅

Reacted to "3 mins for the talk. 27 mins for the spice" with 😅

Reacted to "3 mins for the tal..." with 😅

Reacted to "3 mins for the tal..." with 😅

Reacted to "3 mins for the tal..." with 😅

Reacted to "3 mins for the talk...." with 😅

Reacted to "3 mins for the tal..." with 😅

Reacted to "3 mins for the talk...." with 😅

Reacted to "3 mins for the talk...." with 😅

Reacted to "3 mins for the talk. 27 mins for the spice" with 😅

Reacted to "3 mins for the tal..." with 😅

Reacted to "3 mins for the talk. 27 mins for the spice" with 😅

Reacted to "3 mins for the talk. 27 mins for the spice" with 😅

Replying to "3 mins for the tal..." I wanted to skip today, but then I remembered I still have some🍿 at home

Replying to "Yeah I don’t see how..." because straight forward erasure coding won’t give us the property of partial custody when we have mandatory proofs. Peers would waste bandwidth for parts of the payload they don’t need

Reacted to "3 mins for the tal..." with 😅

Reacted to "3 mins for the talk. 27 mins for the spice" with ❤️

Reacted to "3 mins for the talk. 27 mins for the spice" with 🍿

Replying to "Either RS or RLNC ju..." RS is fully compatible with KZG commitments for signature verification on only one. And RLNC doesn’t even need it and can deal with cheaper commitments

Reacted to "3 mins for the tal..." with 😅

Reacted to "3 mins for the tal..." with 😅

Reacted to "3 mins for the tal..." with 🍿

Reacted to "3 mins for the talk. 27 mins for the spice" with 😅

Replying to "like almost 99% of..." ok, sure, the point is to make sure that if one is going to change this, then the main bottleneck is addressed

Replying to "Either RS or RLNC ju..." Yep I think blobs currently use RS + KZG

Reacted to "RS is fully compatible with KZG commitments for signature verification on only one. And RLNC doesn’t even need it and can deal with cheaper commitments" with 👍

Replying to "Yeah I don’t see how..." That’s not true right? Just do the same as we do with DAS just on a separate topic just for the payload

Reacted to "3 mins for the talk. 27 mins for the spice" with 😅

Replying to "Yeah I don’t see how..." The whole point is that mixing in the column payload data with blob data just doesn’t seem to work on the current slot pipeline

Replying to "Either RS or RLNC ju..." @terence >Ya that would be faster this won’t be faster. We would waste bandwidth for chunks of payload we don’t need to custody

Replying to "Either RS or RLNC ju..." Hm. That’s not how I understood RLNC. But I could be wrong

If the proposal is implemented, we will make centralisation way worse. Big players will survive low issuance, while small ones will die out.

Reacted to "If the proposal is i..." with 👍🏽

Reacted to "If the proposal is i..." with 👍🏽

Reacted to "If the proposal is implemented, we will make centralisation way worse. Big players will survive low issuance, while small ones will die out." with 👍🏽

Replying to "If the proposal is i..." Exactly same at high % ETH staked

Regarding 8363 - is the main goal to not allow 50%+ staked or the the fact that the current issuance is too high or both? if the goal is to not allow 50%+ we could achieve a hard stop when we reach this.

Reacted to "If the proposal is implemented, we will make centralisation way worse. Big players will survive low issuance, while small ones will die out." with 👍🏽

Replying to "If the proposal is i..." Assuming we get there, which we won't

Reacted to "If the proposal is implemented, we will make centralisation way worse. Big players will survive low issuance, while small ones will die out." with 👍🏽

Replying to "If the proposal is i..." Not. With the current curve there is no such a thing as 0% APR

Replying to "Either RS or RLNC ju..." I was talking about RS. For RLNC there is still an open quesion for authenticity of chunks

Replying to "Regarding 8363 - is ..." It is not possible to completely separate these two things - any change to the isssuance policy unavoidably affects both

Replying to "If the proposal is i..." And it’s not exactly the same, because in the snail curve well capitalized actors can push the market to 0% nominal yield for long enough to push out other actors, who will not enter back into the market later

Reacted to "3 mins for the talk. 27 mins for the spice" with 😅

Reacted to "And it’s not exactly the same, because in the snail curve well capitalized actors can push the market to 0% nominal yield for long enough to push out other actors, who will not enter back into the market later" with 💯

Replying to "Regarding 8363 - i..." That's one of the main contradictions of the EIP: If the goal is to avoid extreme staking, no need a full issuance redisign.

Id push back on low complexity. Line of changes != complexity implementation. Any state transition change should be carefully reviewed

Replying to "3 mins for the talk...." we need soundracks

Reacted to "Id push back on low ..." with 👍🏽

Reacted to "3 mins for the talk. 27 mins for the spice" with 😅

Reacted to "3 mins for the talk. 27 mins for the spice" with 🍿

Replying to "If the proposal is implemented, we will make centralisation way worse. Big players will survive low issuance, while small ones will die out." Also isn't 0% in other one for large actors due to mev rewards

Reacted to "I wanted to skip today, but then I remembered I still have some🍿 at home" with 🤣

Heeft gereageerd op "Id push back on lo..." met 👍🏽

Reacted to "I wanted to skip today, but then I remembered I still have some🍿 at home" with 🤣

Replying to "If the proposal is i..." Real yield (and real returns) is not nominal yield accounting for supply inflation, it’s nominal yield accounting for price inflation, and you can still have real returns at very high stake rate even when dilution is very high

Reacted to "3 mins for the talk. 27 mins for the spice" with 😅

Replying to "If the proposal is i..." Believing that we will get to high % ETH staked or not is an opinion. I am not willing to risk it, there’s no undo button then

Reacted to "Id push back on lo..." with 👍🏽

Reacted to "Id push back on low complexity. Line of changes != complexity implementation. Any state transition change should be carefully reviewed" with 👍🏽

Reacted to "Id push back on lo..." with 👍🏽

Replying to "If the proposal is i..." MEV rewards are a pittance these days and do we really want to push validators to MEV maximize as the only way to make money?

Replying to "Regarding 8363 - is ..." How so? Why could not just limit how much eth staked could earn rewards?