Indeed those periods are also governed by the duration of cycles (in blocks), and thus this would reduced the "wall-clock time that the information is reduced. That said, the node can be configured to keep additional cycles:
https://tezos.gitlab.io/user/history_modes.html#keeping-additional-cycles
67% of the (active) baking power is a good approximation. Technically the attestation requirement it >67% of all attesting power in the consensus committee for that level, or over 2/3 of the 7000 slots.
While this is a valid concern, we are confident we can gather enough support from bakers to reach to the minimal threshold.
The experience with the activation of the DAL in Ghostnet provided a good floor of engagement we can expect from bakers. Moreoever, on mainnet today, we already have 30+ bakers running a DAL attester. We will increase our advocacy and education efforts to make sure we are ready.
Iāve just started playing with etherlink and I double what @borsss is saying. Having 15 days for a bridge to happen is just not possible, if etherlink expect to drive adoption is should be instant. All other stuff Iāve tried are super fast but the L1 bridge etherlink to tezos network is a no go.
The experience should be fast and smooth. Donāt know exactly what was the underlying technological issue regarding that but if this can be prio it will be one of the biggest pain point addressed.
I donāt believe lowering refutation times is a tenable solution here. It will never be as fast as you want it to be (or at least as fast at I want it to be) anyway. To some extent the mechanism needs to not just be credible but obviously credible. Right now anything less than a few days I would need to be convinced.
Short term the pain point is entirely with fungible tokens and typically in small amounts. It should not be a major hurdle to have a pool on the tez side and allow instant transfers for a small fee. I unfortunately donāt think this happens naturally, but it does need to. I simply take it as a sign Etherlink is actually in alpha and not ready for me to take a serious look at yet.
Other than that I think weāre waiting for state migration or zk? A few years.
The development team is currently working on a fast withdrawal feature for Etherlink.
The next Etherlink upgrade announcement will include information about how it works. Then the team will need to do additional work on the infrastructure and user interface before it will be available for use.
We will report on the progress of each of these features as they are completed.
I would like to retract this after looking more at the protocol I think I have much larger security concerns I might need to be convinced of and in the mean time setting wait time to zero is consistent with my current trust assumptions.
Looks like the gas fee for transfers is going up in R, but thereās no mention of this in this thread - whatās the rationale behind the increase?
Thank you all for your participation in this feedback request process for protocol R.
Our R protocol proposal will include the features presented in this thread, after their last revision. It will also include other minor changes and bugfixes, which can be found in the next protocolās Changelog.
We are aware, and have taken notice of, other features and suggestions developed in this thread. We will carefully analyse them and consider their potential inclusion in future protocol proposals.
The protocol proposal is currently in stabilization. Once this process concludes satisfactorily, the protocol proposal will be published shortly after. At this time, we would like to invite all willing ecosystem members to join the stabilization effort by participating in the nextnet test network.
Thank you again for your participation! Letās continue building a great future for Tezos together.
According to the changelog, the increase in gas costs for transfers is touted as a āgas improvementā but still no rationale has been postedā¦ If there is a good reason why itās in R this should be clearly stated somewhere - either in this thread or in the docs.
Otherwise, itās not clear why was this particular change was prioritised for the release over others, nor why it needed doing. Non-technical end users or bakers wonāt easily be able to evaluate this change (or others - Iām just picking this one as an example) and thus determine its weight amongst the others as to whether to vote in favour of the release as a whole or not.
IMO making any protocol change big or small should have the reason behind it made clear, along with any of the data or modelling that was made to back it upā¦
edit: screenshot from the MR. The āWhyā section is emptyā¦
From the tests in the MR, this change appears to increase fees for implicit transfers by approximately 50%. Considering shorter cycles, this will primarily impact delegators and bakers making payouts to delegators.
Thanks for bringing this up @borsss.
Indeed, we managed this one as a maintenance among others. The reason for this change is that the gas fees were too low compared to the storage costs. So we increased them in this proposal.
