Profile of zachobront in Optimism
Posts by zachobront
-
Developer Advisory Board Feedback & Ideas Thread
by zachobront - No Role
Posted on: Sept. 4, 2024, 12:37 p.m.
Content: @danelund.eth made a great suggestion to take on an analysis project around the “success” of previous builders grants, so we can start tracking some ongoing data around whether these metrics have improved with DAB’s feedback.
Likes: 1
Replies: 0
No replies yet.
-
Upgrade Proposal #10: Granite Network Upgrade
by zachobront - No Role
Posted on: Aug. 20, 2024, 2:50 p.m.
Content: On behalf of the Developer Advisory Board, we approve this upgrade to move to a vote.
Likes: 3
Replies: 0
No replies yet.
-
Developer Advisory Board Feedback & Ideas Thread
by zachobront - No Role
Posted on: July 15, 2024, 2:19 p.m.
Content: As a part of the Season 6 Charter 4 for the Developer Advisory Board, one of the explicit goals is to uncover additional areas in the Collective where technical support would be helpful.
To that end, we are opening this thread as a place for the community to surface ideas for where the DAB could be helpful, especially in moving towards the Intents for Season 6 .
Additionally, we have added 3 community calls to the OP Governance Calendar 4 , with an emphasis on collecting feedback and generating ideas:
August 13 th at 3 pm ET / 7 pm UTC
October 8 th at 3 pm ET / 7 pm UTC
December 3 rd at 3 pm ET / 7 pm UTC
All ideas from this thread and the calls will be added to our Internal DAB Idea Tracker 9 for the team to process and work on. We’ll share updates here, as well as a full report of the ideas we explored and our conclusions before the end of the Season, which will inform an expanded Charter in Season 7 .
Looking forward to hearing your ideas!
Likes: 9
Replies: 0
No replies yet.
-
Developer Advisory Board Feedback & Ideas Thread
by zachobront - No Role
Posted on: July 15, 2024, 2:19 p.m.
Content: As a part of the Season 6 Charter for the Developer Advisory Board, one of the explicit goals is to uncover additional areas in the Collective where technical support would be helpful.
To that end, we are opening this thread as a place for the community to surface ideas for where the DAB could be helpful, especially in moving towards the Intents for Season 6 .
Additionally, we have added 3 community calls to the OP Governance Calendar, with an emphasis on collecting feedback and generating ideas:
August 13 th at 3 pm ET / 7 pm UTC
October 8 th at 3 pm ET / 7 pm UTC
December 3 rd at 3 pm ET / 7 pm UTC
All ideas from this thread and the calls will be added to our Internal DAB Idea Tracker for the team to process and work on. We’ll share updates here, as well as a full report of the ideas we explored and our conclusions before the end of the Season, which will inform an expanded Charter in Season 7 .
Looking forward to hearing your ideas!
Likes: 9
Replies: 0
No replies yet.
-
Developer Advisory Board - S6 Internal Operating Procedures
by zachobront - No Role
Posted on: July 13, 2024, 2:44 a.m.
Content: Good call on the Upgrade Czar not necessarily agreeing with the “no” upgrade vote. I’ve amended the IOPs to take this into account.
What’s the best way to get integrated into Charmverse? Let’s aim to start with a spreadsheet for the first cycle so new members can focus more on the feedback and not be distracted by new tooling, but would love to make sure we’re set up in Charmverse before the end of the season.
Likes: 2
Replies: 0
No replies yet.
-
Developer Advisory Board - S6 Internal Operating Procedures
by zachobront - No Role
Posted on: July 8, 2024, 10:34 p.m.
Content: The internal operating procedures in this document govern the activities of the Season 6 Developer Advisory Board. The document sets forth the processes the DAB will follow in fulfilling our charter, including supporting the grants council, token house, and citizens with evaluating mission requests, mission applications, and protocol upgrades.
1 ) Mission Applications
The DAB will review all technical mission applications per Grant Council request. Our process to perform this duty is:
The Grants council will provide a list of applications they would like feedback on at least 7 days before the end of each voting cycle.
DAB Ops Lead will organize the requests in a spreadsheet, which will be shared with the DAB, with three phases of assignment: ( 1 ) any applications that interact with the core roadmap will be assigned to one of the reps from OP Labs or Base, ( 2 ) DAB Members will have 24 hours to proactively claim applications to review, ( 3 ) after 24 hours, Ops Lead will randomly assign the remaining applications such that each application has 2 - 3 reviewers (depending on the quantity to review).
Feedback will be provided in the spreadsheet with at least 72 hours left in the cycle, with each application given one of the following indications: yes, no, or veto.
In the event of a veto, other DAB members will be invited to review. In the case of a unanimous veto, the DAB will veto the mission application. Otherwise, no veto action will be taken.
After feedback has been provided, the Grants Council will have the option to set up a call to review feedback and discuss details, if they have any questions. All feedback (besides vetos) will be non-binding, and the Grants Council can take it into account as they see fit.
Feedback will also be shared publicly by the DAB directly on the Mission Request Application in Charmverse, to provide insight to applicants (as well as the opportunity to clarify or improve their application).
2 ) Protocol Upgrades
The DAB is responsible for providing plain English summaries of upgrades and blocking upgrades they believe are unsafe (by withholding the approval comment on the forum draft post). Our process to perform this duty is:
When a new upgrade is posted to the forums, the Upgrade Czar (together with the DAB Lead) will review and write a plain english summary within 72 hours.
The Upgrade Czar will also share the summary with the DAB, along with their opinion on whether the upgrade is safe.
If any DAB member believes that approval should be withheld, the DAB will set up a call to discuss, which will end with a vote.
If a simple majority of DAB members vote “no”, the DAB will withhold the approval comment. The Upgrade Czar (or, in the case that the Upgrade Czar disagrees with the vote, another member) will be responsible for writing up an explanation to share with the community documenting the reasoning and what would be required for the DAB to be comfortable accepting the upgrade.
In the event that any DAB member abstains and the result is a tie, the DAB Lead will make the final decision.
3 ) Reactive Feedback & Support
The DAB will be available to provide a la carte technical feedback to other councils and board who request it. Our process to perform this duty is:
Any council or board can reach out to the DAB either by (a) tagging the board on Discord (@Developer Advisory Board), (b) tagging any member of the board in a forum post or (c) reaching out to any DAB member directly.
Any requests will be shared with the DAB to allow members to proactively offer to help.
If no proactive offers are made, the DAB Lead will assign the project to a DAB Member.
When relevant, the DAB Member who provided the feedback will share a summary of the request and feedback provided on the forum in case the community can benefit from it.
Examples of this type of work include: feedback on Mission Requests, reviewing milestones on existing grants, requests for brainstorming or code review from OP Labs, helping OP Labs find talent in their hiring process, etc.
4 ) Discovering New Ways to Support the Collective
While the processes above are the core responsibilities of the DAB, a part of our Season 6 mission is to discover and expand our ability to support the collective. Our process to perform this duty is:
A “Developer Advisory Board Feedback” thread will be created on the Optimism forum where community stakeholders can make requests, give feedback, and share ideas.
Community calls will be scheduled bimonthly (in July, September and November) to discuss ideas and feedback with the community. Summaries of these calls will be posted on the above thread.
The DAB will proactively explore best ideas (based on subjective judgment), using the forum thread as the source of truth for all ideas. Each DAB member will be expected to experiment with at least one idea over the course of the season.
At end of season, the DAB will share a summary on the forum of exactly what experiments were run, the results, which ideas will persist as core responsibilities next season, and the best ideas remaining to be tried in the future.
Likes: 7
Replies: 1
Replies:
- Gonna.eth: zachobront:
The Grants council will provide a list of applications they would like feedback on at least 7 days before the end of each voting cycle.
It would be nice to see how to standardize this process. We could start with a spreadsheet but the end game would be for the DAB to be integrated into Charmverse with their role and permissions. Data exportation between platforms is where we found most of the GC errors.
zachobront:
(2) DAB Members will have 24 hours to proactively claim applications to review, (3) after 24 hours, Ops Lead will randomly assign the remaining applications such that each application has 2-3 reviewers (depending on the quantity to review).
This is such a nice way to do app distribution!
zachobront:
If a simple majority of DAB members vote “no”, the DAB will withhold the approval comment. The Upgrade Czar will be responsible for writing up an explanation to share with the community documenting the reasoning and what would be required for the DAB to be comfortable accepting the upgrade.
Situation: Czar votes yes, 2 other DAB members vote no. It wouldn’t be better if the reasoning document came from those who voted no and the requirements. Maybe a change of Czar could be implemented? Would it be possible for the Czar not to have enough context enough and say “I want to appoint X as a Czar since his/her knowledge is deeper”
zachobront:
Community calls will be scheduled bimonthly (in July, September and November) to discuss ideas and feedback with the community. Summaries of these calls will be posted on the above thread.
I can’t wait to have DAB office Hours
-
Developer Advisory Board - S6 Internal Operating Procedures
by zachobront - No Role
Posted on: July 8, 2024, 10:34 p.m.
Content: The internal operating procedures in this document govern the activities of the Season 6 Developer Advisory Board. The document sets forth the processes the DAB will follow in fulfilling our charter 3 , including supporting the grants council, token house, and citizens with evaluating mission requests, mission applications, and protocol upgrades.
1 ) Mission Applications
The DAB will review all technical mission applications per Grant Council request. Our process to perform this duty is:
The Grants council will provide a list of applications they would like feedback on at least 7 days before the end of each voting cycle.
DAB Ops Lead will organize the requests in a spreadsheet, which will be shared with the DAB, with three phases of assignment: ( 1 ) any applications that interact with the core roadmap will be assigned to one of the reps from OP Labs or Base, ( 2 ) DAB Members will have 24 hours to proactively claim applications to review, ( 3 ) after 24 hours, Ops Lead will randomly assign the remaining applications such that each application has 2 - 3 reviewers (depending on the quantity to review).
Feedback will be provided in the spreadsheet with at least 72 hours left in the cycle, with each application given one of the following indications: yes, no, or veto.
In the event of a veto, other DAB members will be invited to review. In the case of a unanimous veto, the DAB will veto the mission application. Otherwise, no veto action will be taken.
After feedback has been provided, the Grants Council will have the option to set up a call to review feedback and discuss details, if they have any questions. All feedback (besides vetos) will be non-binding, and the Grants Council can take it into account as they see fit.
Feedback will also be shared publicly by the DAB directly on the Mission Request Application in Charmverse, to provide insight to applicants (as well as the opportunity to clarify or improve their application).
2 ) Protocol Upgrades
The DAB is responsible for providing plain English summaries of upgrades and blocking upgrades they believe are unsafe (by withholding the approval comment on the forum draft post). Our process to perform this duty is:
When a new upgrade is posted to the forums, the Upgrade Czar (together with the DAB Lead) will review and write a plain english summary within 72 hours.
The Upgrade Czar will also share the summary with the DAB, along with their opinion on whether the upgrade is safe.
If any DAB member believes that approval should be withheld, the DAB will set up a call to discuss, which will end with a vote.
If a simple majority of DAB members vote “no”, the DAB will withhold the approval comment. The Upgrade Czar (or, in the case that the Upgrade Czar disagrees with the vote, another member) will be responsible for writing up an explanation to share with the community documenting the reasoning and what would be required for the DAB to be comfortable accepting the upgrade.
In the event that any DAB member abstains and the result is a tie, the DAB Lead will make the final decision.
3 ) Reactive Feedback & Support
The DAB will be available to provide a la carte technical feedback to other councils and board who request it. Our process to perform this duty is:
Any council or board can reach out to the DAB either by (a) tagging the board on Discord (@Developer Advisory Board), (b) tagging any member of the board in a forum post or (c) reaching out to any DAB member directly.
Any requests will be shared with the DAB to allow members to proactively offer to help.
If no proactive offers are made, the DAB Lead will assign the project to a DAB Member.
When relevant, the DAB Member who provided the feedback will share a summary of the request and feedback provided on the forum in case the community can benefit from it.
Examples of this type of work include: feedback on Mission Requests, reviewing milestones on existing grants, requests for brainstorming or code review from OP Labs, helping OP Labs find talent in their hiring process, etc.
4 ) Discovering New Ways to Support the Collective
While the processes above are the core responsibilities of the DAB, a part of our Season 6 mission is to discover and expand our ability to support the collective. Our process to perform this duty is:
A “Developer Advisory Board Feedback” thread will be created on the Optimism forum where community stakeholders can make requests, give feedback, and share ideas.
Community calls will be scheduled bimonthly (in July, September and November) to discuss ideas and feedback with the community. Summaries of these calls will be posted on the above thread.
The DAB will proactively explore best ideas (based on subjective judgment), using the forum thread as the source of truth for all ideas. Each DAB member will be expected to experiment with at least one idea over the course of the season.
At end of season, the DAB will share a summary on the forum of exactly what experiments were run, the results, which ideas will persist as core responsibilities next season, and the best ideas remaining to be tried in the future.
Likes: 7
Replies: 1
Replies:
- Gonna.eth: zachobront:
The Grants council will provide a list of applications they would like feedback on at least 7 days before the end of each voting cycle.
It would be nice to see how to standardize this process. We could start with a spreadsheet but the end game would be for the DAB to be integrated into Charmverse with their role and permissions. Data exportation between platforms is where we found most of the GC errors.
zachobront:
(2) DAB Members will have 24 hours to proactively claim applications to review, (3) after 24 hours, Ops Lead will randomly assign the remaining applications such that each application has 2-3 reviewers (depending on the quantity to review).
This is such a nice way to do app distribution!
zachobront:
If a simple majority of DAB members vote “no”, the DAB will withhold the approval comment. The Upgrade Czar will be responsible for writing up an explanation to share with the community documenting the reasoning and what would be required for the DAB to be comfortable accepting the upgrade.
Situation: Czar votes yes, 2 other DAB members vote no. It wouldn’t be better if the reasoning document came from those who voted no and the requirements. Maybe a change of Czar could be implemented? Would it be possible for the Czar not to have enough context enough and say “I want to appoint X as a Czar since his/her knowledge is deeper”
zachobront:
Community calls will be scheduled bimonthly (in July, September and November) to discuss ideas and feedback with the community. Summaries of these calls will be posted on the above thread.
I can’t wait to have DAB office Hours
-
Upgrade Proposal #9: Fjord Network Upgrade
by zachobront - No Role
Posted on: June 5, 2024, 5:22 p.m.
Content: On behalf of the Developer Advisory Board, here is a non-technical summary of this upgrade proposal:
The Fjord upgrade packages together five changes that are somewhat related, but can be considered separately for simplicity.
1 ) secp 256 r 1 Precompile
Your phone actually has its own private key. It’s hardcoded in there and is inaccessible, except when you present biometric data like a thumbprint or FaceID. If it was on the secp 256 k 1 curve, your phone would be able to have a built in Ethereum wallet.
But it’s on a different cryptographic curve called secp 256 r 1 . That means that if your phone signs something with its private key, it’s not an Ethereum signature. It can’t send a transaction on chain. But it can be verified on chain that it was your phone that signed it! It would just cost a lot of gas to do it.
This upgrade implements a precompile contract at the address 0 x 0000000000000000000000000000000000000100 . This contract allows users to send a hash, a signature, and a public key. It will return whether the signature is valid or invalid, and it uses a lot less gas than it would otherwise take.
This will make it possible to cheaply create “smart accounts” that are controlled by your phone, and adds no risk to the core protocol’s signature scheme, which remains unchanged.
(Note: The secp 256 r 1 curve is used by more than just phones. Check out the RIP- 7212 7 proposal for more examples of use cases this unlocks. The phone is just one example.)
Brotli for Compression
The Optimism sequencer posts all the L 2 transactions to a blob on Ethereum, which is read by nodes to rerun the transactions to reconstruct the state.
The more we can compress those transactions, the cheaper the blob cost (which makes up the majority of L 2 transaction cost) will be.
This upgrade switches from the previous compression algorithm to Brotli (a data compression algorithm developed by Google), which reduces the amount of data we need to post by 5 - 15 %. This means the L 1 portion of the gas cost will be reduced by 5 - 15 %, meaning cheaper transactions.
L 1 Gas Cost Estimates
When you pay for an L 2 transaction, part of the cost comes from the sequencer estimating the cost of posting your data to L 1 as a part of the blob (like described above) and including that in your transaction cost.
Previous estimates were not completely accurate, because they were not able to estimate exactly how much compression would be possible. This meant that users might over or under pay for their actual data usage.
This upgrade implements a new estimate function. It was tested on historical data and found to provide better estimates than the previous algorithm, and to never diverge substantially from the correct estimate.
Increase Sequencer Drift
If the sequencer loses its connection with L 1 , it would ideally continue to produce blocks until it regains the connection.
There is a protocol variable called “max sequencer drift” that determines how long the L 2 can continue to produce blocks based on an old L 1 origin. After this point, the L 2 can no longer produce blocks.
This upgrade increases this value from 10 minutes up to 30 minutes to add more flexibility, based on the unanimous agreement of chain operators.
Increase Max Batch Size
As discussed earlier, L 2 transaction data is posted to L 1 . This is done in “channels”, which can group together multiple L 2 blocks. However, we can’t split a single L 2 block across multiple channels — it needs to fit within one.
The maximum channel size is 10 mb. That is more than enough for any normal circumstances, but if an OP Stack chain allowed a gas limit of more than 40 mm (as opposed to Optimism’s 30 mm), a block could theoretically be filled with one transaction with more than 10 million zeros.
This would exceed the 10 mb limit, would not be able to be added to a channel, and therefore would fail to be posted on L 1 to progress the chain.
This upgrade increases the limit to 100 mb, so there is no risk of such a block unless a chain increases their gas limit over 400 mm (which is currently far outside the normal range).
All of these changes appear to be logical, well tested, improvements to the OP Stack, and don’t seem to create any new risks in the core chain or bridge logic.
Likes: 15
Replies: 0
Likers:
Jepsen,
web3magnetic,
lavande,
Tane,
delphine,
Pumbi,
Gonna.eth,
ericbrown,
Jrocki,
habacuc.eth,
SEEDGov,
Joxes,
Luckyhooman.eth,
httpsageyd,
Liliop.eth
No replies yet.
-
Upgrade Proposal #9: Fjord Network Upgrade
by zachobront - No Role
Posted on: June 5, 2024, 5:22 p.m.
Content: On behalf of the Developer Advisory Board, here is a non-technical summary of this upgrade proposal:
The Fjord upgrade packages together five changes that are somewhat related, but can be considered separately for simplicity.
1 ) secp 256 r 1 Precompile
Your phone actually has its own private key. It’s hardcoded in there and is inaccessible, except when you present biometric data like a thumbprint or FaceID. If it was on the secp 256 k 1 curve, your phone would be able to have a built in Ethereum wallet.
But it’s on a different cryptographic curve called secp 256 r 1 . That means that if your phone signs something with its private key, it’s not an Ethereum signature. It can’t send a transaction on chain. But it can be verified on chain that it was your phone that signed it! It would just cost a lot of gas to do it.
This upgrade implements a precompile contract at the address 0 x 0000000000000000000000000000000000000100 . This contract allows users to send a hash, a signature, and a public key. It will return whether the signature is valid or invalid, and it uses a lot less gas than it would otherwise take.
This will make it possible to cheaply create “smart accounts” that are controlled by your phone, and adds no risk to the core protocol’s signature scheme, which remains unchanged.
(Note: The secp 256 r 1 curve is used by more than just phones. Check out the RIP- 7212 proposal for more examples of use cases this unlocks. The phone is just one example.)
Brotli for Compression
The Optimism sequencer posts all the L 2 transactions to a blob on Ethereum, which is read by nodes to rerun the transactions to reconstruct the state.
The more we can compress those transactions, the cheaper the blob cost (which makes up the majority of L 2 transaction cost) will be.
This upgrade switches from the previous compression algorithm to Brotli (a data compression algorithm developed by Google), which reduces the amount of data we need to post by 5 - 15 %. This means the L 1 portion of the gas cost will be reduced by 5 - 15 %, meaning cheaper transactions.
L 1 Gas Cost Estimates
When you pay for an L 2 transaction, part of the cost comes from the sequencer estimating the cost of posting your data to L 1 as a part of the blob (like described above) and including that in your transaction cost.
Previous estimates were not completely accurate, because they were not able to estimate exactly how much compression would be possible. This meant that users might over or under pay for their actual data usage.
This upgrade implements a new estimate function. It was tested on historical data and found to provide better estimates than the previous algorithm, and to never diverge substantially from the correct estimate.
Increase Sequencer Drift
If the sequencer loses its connection with L 1 , it would ideally continue to produce blocks until it regains the connection.
There is a protocol variable called “max sequencer drift” that determines how long the L 2 can continue to produce blocks based on an old L 1 origin. After this point, the L 2 can no longer produce blocks.
This upgrade increases this value from 10 minutes up to 30 minutes to add more flexibility, based on the unanimous agreement of chain operators.
Increase Max Batch Size
As discussed earlier, L 2 transaction data is posted to L 1 . This is done in “channels”, which can group together multiple L 2 blocks. However, we can’t split a single L 2 block across multiple channels — it needs to fit within one.
The maximum channel size is 10 mb. That is more than enough for any normal circumstances, but if an OP Stack chain allowed a gas limit of more than 40 mm (as opposed to Optimism’s 30 mm), a block could theoretically be filled with one transaction with more than 10 million zeros.
This would exceed the 10 mb limit, would not be able to be added to a channel, and therefore would fail to be posted on L 1 to progress the chain.
This upgrade increases the limit to 100 mb, so there is no risk of such a block unless a chain increases their gas limit over 400 mm (which is currently far outside the normal range).
All of these changes appear to be logical, well tested, improvements to the OP Stack, and don’t seem to create any new risks in the core chain or bridge logic.
Likes: 15
Replies: 0
Likers:
Jepsen,
web3magnetic,
lavande,
Tane,
delphine,
Pumbi,
Gonna.eth,
ericbrown,
Jrocki,
habacuc.eth,
SEEDGov,
Joxes,
Luckyhooman.eth,
httpsageyd,
Liliop.eth
No replies yet.
-
Season 6 Nominations: Developer Advisory Board
by zachobront - No Role
Posted on: May 31, 2024, 1:48 p.m.
Content: @Jepsen @devtooligan @gmhacker @bayardo @merklefruit Amazing applications, thank you all.
We just added one more question to the template:
Are you interested in the Ops Lead or Upgrade Czar roles? If so, please share relevant experience and one idea you have for how the role could contribute to the collective.
If you’re interested in either of these roles, please edit your application to include an answer to this question.
:pray:
Likes: 3
Replies: 0
No replies yet.
