Replies: 5 comments 7 replies
-
|
We should 4x these estimates if we want to consider the end-to-end time between writing the code and getting the requite reviewers' sign-offs. |
Beta Was this translation helpful? Give feedback.
-
|
@jcnelson I recall you mentioned in this Monday's public blockchain call that Stacks 2.1 work items were on track. I might have missed some details though, so I was wondering if you could provide an update here on 1) what's remaining and 2) rough timeline? Is this board up-to-date? If so, happy to use that as the reference, though it's hard to get a sense of time estimates from the board. I think a periodic update on this discussion would also benefit those following this issue but not attending the meetings, and also help inform other stakeholders / community members in case there are places where folks can help chip in to move things along. Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
This document answers (1) and (2) to the best of my knowledge, so I'm not sure what else you're asking for here? This document is edited regularly whenever there's a new PR or a new task to be done. |
Beta Was this translation helpful? Give feedback.
-
|
Got it, thanks. I was looking for an estimate for the overall timeline for Stacks 2.1 work being done. Sounds like you're suggesting one could just go item by item and compute an estimate based on whether a PR exists or work has not yet begun, which I can do. Appreciate it! |
Beta Was this translation helpful? Give feedback.
-
|
Looking at the current 2.1 Items, the following tasks seem to have the highest impact with the help from team at Hiro. I also, added a note on these issues individually. |
Beta Was this translation helpful? Give feedback.
-
|
Also @obycode has volunteered to take a crack at implementing more robust trait semantics per #3231 (comment) |
Beta Was this translation helpful? Give feedback.
-
|
Based on the estimates here and current WIP, here's the code complete and post code complete timeline. Projected Code Complete: Se 09 2022
|
Beta Was this translation helpful? Give feedback.
-
|
Code-completion is still likely at least a week away, when review times are accounted for. Maybe as many as three. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
@saralab could you update this with the dates discussed in Monday's call (https://docs.google.com/document/d/1SA87UgCz0S0YK9zpUFUdDCZkLw-QiyizkHhpk6o_OLk/edit) ? |
Beta Was this translation helpful? Give feedback.
-
|
Updated based on Monday's Blockchain Weekly discussion |
Beta Was this translation helpful? Give feedback.
-
|
Are those "End dates" accurate? I think only start dates were discussed on Monday IIRC |
Beta Was this translation helpful? Give feedback.
-
How to Read this Document
All items marked with
Pain level: very highorPain level: highare required for 2.1. Everything else is informational.The time estimations here are in person-hours spent working on the task, where 1 day is 8 person-hours. These person-hours may be spread across many wall-clock days, depending on whether or not there are other non-2.1 tasks that take precedence. These estimates do not include time taken to review the code.
The associated Github issues' progress can be tracked on the Stacks 2.1 project board.
1-2 days
Consensus bug: wrong microblock fee calculation [[chainstate] parent block miner does not receive 40% of the microblock tx fees #3140]
Fix UTXO chaining [Reliability improvements: UTXO chaining breaks after miner commitments miss intended burnchain block #2358]: This seems to be a 10-line change -- we just need to fix and gate the block height offset calculation. Most of the work is going to be in testing it.
Expose chain ID [Expose chain ID in Clarity #2982]. This is the act of adding a new global variable, and gating its usage (including whether or not it's mainnet or testnet)
Expose burnchain tokens spent for a Stacks block via
get-block-info?or similar, as well as exposing the STX accumulated [[stacks 2.1] expose BTC/STX exchange rate in Clarity #3043]No sortition is possible in the last reward cycle block if the number of reward slots is odd [[burnchain] the block-commit at the end of the reward cycle's pay-out period will never be valid if the size of the reward set is odd #2507]: This is a 10-line change -- we just need to use the correct burn address for mainnet. Most of the work is going to be in testing it.
Tolerate flash blocks in PoX prepare phase [Stacks 2.1: Flash-block resistant PoX anchor selection calculation #2535]: This is a matter of changing the burn window size from w to w - min(M, m), where w = 100 per SIP 007, M is the maximum number of missed sortitions we tolerate (e.g. 10), and m is the actual number of missed sortitions. Most of the work is going to be in testing it.
Check a contract-call's argument count on analysis [VM: analysis pass should consider argument count when deploying a contract #2683]. This is a 10-line bugfix that must be gated. It will take more work to test than to implement.
Enforce the right number of arguments for all native types [[Clarity] use stricter argument count checks #3117]
2-3 days
Codec for Clarity values to/from buffers [Feature request: allow hashing functions to hash other Clarity types #2693]. This is part of SIP-018, which will likely be folded into the Stacks 2.1 SIP. This is a new set of Clarity functions, and would require coordinating with the SIP-018 authors on the semantics.
Bitcoin wire format rigidity [Bitcoin wire format rigidity #2094], if we take the simple approach of just widening the window for which an on-BTC operation will be treated as valid
Extend PoX sunset [[Stacks-2.1] remove PoX sunset and cap unburnt PoX output to be a function of the last prepare phase #2613]. Just remove the sunset; don't touch
(reject-pox); just implement the capped upside for discount-miningRequire PoX anchor block to correspond to the block commit with the most BTC and confirmations [Reliability improvements: require anchor block to have maximum BTC weight #2625]. Blocked on merging Fix/1805 #2707.
Finalize
(at-block)andcontract-call?semantics across Clarity versions and epoch boundaries, and add adequate test coverage [[Clarity] rules for determining which Clarity version to run #3131]Implement getters for all state in
.pox-2and test them [PoX Updates:.pox-infocontract for native information getters #2538]Treat analysis errors found at runtime as runtime errors [[clarity] All check errors must be handled as runtime errors #3107]
Always bill the transaction fee when running a transaction [[chainstate] deduct fee before running the transaction #3213]
Implement getters for the reward set [[clarity] expose PoX reward recipient addresses via
get-burn-block-info?#3155]Implement
.costs-3costs contract [[Clarity] need a.costs-3contract for Stacks 2.1 and associated benchmarking #3115]Get burn header hash by block height
Parse and assemble principals from primitive types
Order-independent transaction signing [Reliability Improvements: order-independent tx signing and verifying #2622]: This requires introducing an additional transaction authentication mode for permitting any order of key signatures, and requires gating its usage until after 2.1 in the block-validation logic and miner. We'd want to rigorously test this, and we'd probably want to introduce a new transaction version value for this. AFAIK no hardware wallets even support multisig yet, so we have a somewhat green field to work with here.
3-7 days
Implement
stacks-unlock[PoX Updates:stack-unlock#2534]Implement
stacks-increase[PoX Updates:stack-increase#2533]stack-increasefor PoX-2 #3282Native segwit support for PoX outputs [PoX: native segwit support #2586]. We'll need to change the type signatures for all
.pox-2methods that take a PoX address, add support for new PoX address versions in.pox-2, and add a variant toStacksAddress(i.e. make it anenum, not astruct) to represent segwit addresses (i.e. witness program version, 32 byte hash). We'll also need to test this rigorously.Update coinbase transaction to pay to contract address [[chainstate] Add support for pay-to-contract in coinbase transaction variant #3101].
Cap upside of discount mining [[burnchain] cap the upside of discount-mining #3095]. This is the act of (a) forcing miners to burn BTC if they spend beyond a given threshold on a block-commit, and (b) figuring out the right way to find the threshold -- i.e. from one or more prepare phases. This will require some exploration of historic chainstate, and will need some rounds of review.
Handle the arrival of a hidden anchor block without reorging the whole chain [Absent PoX anchors should be "forkable" #1805]
Compress Clarity contracts and only bill for loading/storing their compressed representation [[VM] Compress contracts before storing them and decompress on load, and bill the user only for the number of bytes in the compressed representation #2926]. This will require choosing and evaluating a consensus-critical compression algorithm, will require gating the feature, and will require re-assessing the runtime costs in Stacks 2.1 for loading/storing compressed contract data. We'll need to benchmark the new load/store routines end-to-end.
Beta Was this translation helpful? Give feedback.
All reactions