Increase Transaction and Block Memory Units (Part 1 of 2)
395 SPOs voted · 15 with a rationale · 7 changed their vote · 2 re-voted unchanged
Open a row to read the rationale.
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesRationale
I vote yes on increasing the memory units by 25% for both individual transactions and total blocks. Reviewing the research provided by several knowledgeable SPOs, and in talking with expert smart contract engineers on Cardano like The Ancient Kraken, the overwhelming opinion is that this change is necessary and beneficial to Cardano at this time. Just because we are not constantly operating under high chain load currently, every time there is high chain load, this change would remediate several aspects of it. As an engineer involved in some of the large enterprise onboarding to Cardano, the transaction tests we performed, allow for a notably smoother smart contract experience. In addition, certain calculations are simply not possible to perform on chain given the current limits, preventing many more advanced use cases for smart contracts on Cardano, or make their implementation more complex than it could be. An example of this is outlined here: https://github.com/logical-mechanism/peace-protocol/blob/main/documentation/close_out_report.md . Given the predictions by experts in chain analytics on the impact of this increase, my own research and data, and the research of my colleagues, I support this change.
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesNo rationale
- YesRationale
I am voting YES on governance action c21b00f90f18fce4003edf42b0b0d455126e01c946e80cc5341a9f9750caf795, which increases the transaction and block memory unit limits. I'm the original proposer of this change, 2 years ago. Ample work has been done by IOG and others to validate the safety of this change, and I believe we have several times this margin in terms of ability to increase these limits.
You can find a larger writeup of my beliefs and values here.
- YesNo rationale
- YesNo rationale
- YesNo rationale
- AbstainChangedHistory
Earlier votes
No6mo agoSuperseded
- AbstainChangedHistory
Earlier votes
No6mo agoSuperseded
- AbstainChangedHistory
Earlier votes
No6mo agoSuperseded
- AbstainChangedHistory
Earlier votes
No6mo agoSuperseded
- AbstainChangedHistory
Earlier votes
No6mo agoSuperseded
- AbstainNo rationale
- AbstainChangedHistory
Earlier votes
No6mo agoSuperseded
- AbstainChangedHistory
Earlier votes
No6mo agoSuperseded
- AbstainNo rationale