Replies: 11 comments 33 replies
-
Scope |
Beta Was this translation helpful? Give feedback.
-
|
Proposed FIPs to be considered by @anorth :
|
Beta Was this translation helpful? Give feedback.
-
|
Lotus team did a first pass review on the proposed FIPs and agreed that:
may fit in one network upgrade v nicely, and all of them may bring very positive impact to the network. Based on the new states that's getting added to the market actor and the potential impl work + it's immediate impact - we think it's better to have the "contact as deal clients" in a later upgrade. We need more clarity on FIL+ indefinite proposal and then will follow up on a more detailed evaluation including work scope and so on for determining a deliverable timeline next week. Note from our team from a community perspective (more for TPMs):
|
Beta Was this translation helpful? Give feedback.
-
|
@jennijuju how about we keep the FVM Phase 2 for NV18? Brining in external EVM foreign actors will bring in additional complexity (i'm assuming?). Thus for NV17 we could focus on refractor & the other proposed FIPs (Set PCD independent of sector content, make FIL+ more independent from the built-in storage-market actor, rearchitect for programmable storage markets). This will also allow Forest team to catch up to NV16 with much ease as well. |
Beta Was this translation helpful? Give feedback.
-
|
Re: nv 18: I think that will depend on fvm m2 scope and dev resource & time needed - fvm team is going to start scoping that out in June, so Id suggest us wait for that before opening nv18 discussion. I think one retro topic id like us to discuss is, _did pre-commit network v16 upgrade to fvm m1 slow the rest of the network development? Should we always only consider existing FIP (at least in Draft status and up) for future network upgrade scoping? _ (cc @kaitlin-beegle in case you are keeping retro items somewhere! re: nv17 scope is being proposed here: https://github.com/filecoin-project/tpm/discussions/91#discussioncomment-2817484, wanna add your items and we can discuss tgt in next core dev call? |
Beta Was this translation helpful? Give feedback.
-
|
Re: nv 18: Yes, make sense. Let's wait for the FVM team to scope things out. I agree, this is a good item to discuss - I would say pre-commiting network v16 upgrade with FVM M1 did slow the progress. However, this was necessary as FVM is/was such a large milestone for the Filecoin network. However, not a good idea to do this repeatedly. Re: nv 17 scope: I'll try to go through the FIPs before the next call & add items to the thread. |
Beta Was this translation helpful? Give feedback.
-
Timeline |
Beta Was this translation helpful? Give feedback.
-
|
The timeline of this upgrade is partially dependent on FVM phase 2 deliver time. |
Beta Was this translation helpful? Give feedback.
-
|
Following weeks of deliberation (see: #fil-fips, and/or the Core Devs meeting notes) the timeline for this upgrade is decided as follows:
Exact dates will be determined in the coming weeks, when team leads have returned from vacation. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks Jenn! I'll pause to understand what's in nv16 before dumping stuff in here. |
Beta Was this translation helpful? Give feedback.
-
|
I've started discussion motivating the FIL+ changes here: filecoin-project/FIPs#313 I've also been working on implementation design. The work in progress is available at https://www.notion.so/pl-strflt/FIL-indefinite-term-limits-08079d7ec25c4cae839a3bf95a82df26 . This will feed into a FIP draft. |
Beta Was this translation helpful? Give feedback.
-
Support contracts as deal clients is the single highest near-term impact change. If I was only able to have one change, I would take that one. It doesn't make sense to take the others and not that one. I would like to see somewhere the discussion about "potential impl work", since I believe the change requires basically no implementation work for backwards compatibility, and new work only for providers who wish to use the new capability. Why does the new states cause a problem? |
Beta Was this translation helpful? Give feedback.
-
|
The rearchitecture for programmable storage markets is a huge change, and will definitely involve work in the implementations. If there's one that might need to slip to after M2, it's that one. If we do decide to defer that, we should take care to prevent contracts being written that can call into methods that we intend to change or remove. We can probably do this with a careful audit of the caller requirements of all actor methods (we should probably do this anyway). |
Beta Was this translation helpful? Give feedback.
-
|
FIP0029 beneficiary address should be in scope. |
Beta Was this translation helpful? Give feedback.
-
|
Agreed. FIP0029 is an independent change and back-compliant, not that complicated but it will immediately bring the ecosystem a more flexible way for collaboration on capital collaboration. |
Beta Was this translation helpful? Give feedback.
-
|
As discussed in the May 19th core dev call, I'd like to propose to descope nv17. The idea is to keep nv17 as small as possible so that:
To better help the implementation teams to plan out resources for supporting this upgrade, I want to suggest implementers propose the FIPs & other improvements that should be considered for nv17 by June 1st. The core devs then can review & discuss the proposals during the core dev call on June 2nd. cc @kaitlin-beegle @anorth @raulk @lerajk @steven004 @arajasek |
Beta Was this translation helpful? Give feedback.
-
|
I would like to propose filecoin-project/FIPs#380 which has the most merit if it lands in upgrade before the main bulk of changes related to miner and storage markets (which we are working towards). |
Beta Was this translation helpful? Give feedback.
-
|
Another proposal: predictable actor address generation. filecoin-project/FIPs#379 (pre-FIP) |
Beta Was this translation helpful? Give feedback.
-
@momack2 has a great suggestion on how to execute an upgrade for this purpose:
I think this is also a good idea for the practise, if we decide to do so, the proposed FIPs can be scheduled for nv18 upgrade, and the scope can be slightly bigger according to what changes are gonna be included and implementation team resources. |
Beta Was this translation helpful? Give feedback.
-
|
If the core goal is to efficiently get the whole community used to the new network upgrade process, IMHO best to make that a PART of this upgrade with a built in "new upgrade training" phase immediately following the nv16 upgrade so folks practice the new process immediately. This proposal would overlap the eng testing/hardening of nv16 and nv17 (due to the very small delta between the versions), and bundle the monitoring / release-process energy from implementation teams into a single window (instead of repeat interruptions). It does have some risks (ex that SPs/exchanges disengage after the first upgrade and miss the second one), but seems significantly lower effort for impl teams than doing a "small" release in late July that requires a whole separate network upgrade release/testing process. However, I'm not 100% convinced we need this "practice" release - and would also be fine with the decision to just immediately proceed to an actor-FIP-tastic nv17. 💪 |
Beta Was this translation helpful? Give feedback.
-
|
I'm not 100% convinced we need a "practice" release either, but it should be fine we keep nv17 very simple. However, I would think one week between nv16 and nv17 might not be enough. Upgrading is a big thing for storage providers, every time we will see some are struggling to make the upgrading work and stable. And we know, nv16 is a really big change, let's have some time to stabilize it first. I would suggest 2 weeks. |
Beta Was this translation helpful? Give feedback.
-
|
base on the core dev calls on Jun 16th, the main scope is around enabling loan markets & programmable storage markets before M2. FIPs on this epic being proposed atm:
Currently, most of the FIPs have an tentative DRI for implementation assigned, other than Re-architecture for programmable markets. and sounds like we are going to be act on "best effort basis on the time given (how much time we have before the nv17 upgrade)" for it.
(I personally agree with Anorth that unlock storage market programmability will enable a lot interesting use case & market place on filecoin with FVM M2 later, therefore, id 💯 on dedicating a development cycle & network upgrade on it. @anorth wondering what do you think the largest blocker would be for scoping in |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for summarizing your thoughts here, @jennijuju! I agree, especially with the idea that we should have implementation teams scope implementation design and estimate resources/capacity needs before confirming the scope. I think we are nearly able to more firmly specify the list of FIPs- but first, a few questions for others:
Additionally, an open question for everyone: should we also consider including #390 in v17? My initial preference is no, but I could be easily swayed if the actual implementation change would be a light lift. I'd love implementers to take a look at this FIP and estimate the amount of work required to implement. |
Beta Was this translation helpful? Give feedback.
-
|
@jennijuju thanks for your enthusiasm. Regarding the Re-architecture for programmable markets:
I will try to do that re-design work this week. @kaitlin-beegle mostly the other FVM/interop stream targets M2 itself. There would be little network advantage to shipping those changes in nv17 because they would be unused until M2. The main advantage would be to reduce the scope/complexity of the changes landing all together in M2, to make that easier. I should note that @raulk disagrees that pulling changes forward is advantageous. Removing unwanted actor code, and the #390 is likely to be pretty light implementation work – the real effort is in modelling/analysis. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry for the delay in chiming in here. It was hard to give a qualified opinion prior to nv16 deployment (and us having an opportunity to evaluate how things ultimately panned out, and what may need adjustment!). At this stage, the FVM team is fully focused on FEVM. Shipping a minor set of changes ahead of FEVM would imply a detour and it would split our focus. So far we haven't detected anything pressing that warrants that action; everything else can wait until the FEVM update and subsequent introduction of user programmability. Once that is out, making changes may imply breaking code that we don't control, so trimming of unwanted surfaces may no longer be a straightforward option later. So I'll speak for the FVM team and say that we don't foresee shipping any changes in nv17, unless the situation on the ground changes between now and then. |
Beta Was this translation helpful? Give feedback.
-
|
@kaitlin-beegle could you please remind me whats the strategy of scope lock down again? |
Beta Was this translation helpful? Give feedback.
-
|
Oh but of course :) I still have a few open questions that I'm looking to answers to (above), but I expect to be able to further specify our list of potential FIPs at the next Core Devs call. During this call we'll also hear from the CEL team about the Sector Duration Multiple for Longer Term Storage Deals proposals, so it will be a good opportunity for implementers to consider whether this is scope appropriate (as depending on their capacity). In the meantime, I'm also going to flag for implementation teams to begin thinking about implementation capacity demand for some of the FIPs that we're seriously considering including. However, aside from simply making the ask, I'm not sure if there's a best way to coordinate this- if you have a preference, let me know! Otherwise, I'll assemble an open priority order of FIPs in a Notion page, share it with each team early next week, and ask them to begin to think about implementation design. Our ability to lock down the scope depends on teams reviewing the current FIP list and letting their preferences be known; however, I anticipate that we can begin to do so in the next week or 2. Lastly, I know you and @lerajk had suggested we have a cut-off dates for FIPs that can be accepted into the upgrade- I personally don't think this is necessary. It will just be another date that needs to be communicated. We currently have more FIPs than we can implement, so if anything else is added, Core Devs can simply confirm that there is no space for inclusion. The only caveat here is that some of the proposed FIPs that @anorth is putting forth aren't available as drafts yet- I don't think this is a problem, and we can work together to ensure that any proposed enhancement has all proper FIP documentation in time. If either of you disagree, however, I'm all ears! Does that fully answer your question? Do you have any outstanding uncertainties that we can address? |
Beta Was this translation helpful? Give feedback.
-
Just noting that I am intentionally planning for some implementation work to precede formal FIP drafts, as that work helps us discover unexpected interactions and be confident about the concrete change being proposed. If this flow causes a problem, I can easily create draft FIPs that have some placeholders or uncertain decisions, so we can assign a FIP number. I can see how this could help communication. |
Beta Was this translation helpful? Give feedback.
-
|
In consultation with @arajasek and @jennijuju I have drafted a proposal for a technical scope for nv17. Without a concrete scope we've been lacking ability to make decisions about priorities and timelines. The items are still subject to governance approval, but this is my proposal for a concrete plan. https://pl-strflt.notion.site/Filecoin-nv17-technical-scope-proposal-c7733fe047d8412eacd713ec5905d7e5 Very roughly, I would project this scope gets us an upgrade in early October. There is significant room to expand scope and take a bit longer, and a small opportunity to reduce scope to either bring the upgrade closer or at least improve our confidence in timeline. From my POV, the main constraint on expanding scope is a perceived need to "get out of the way" for a network upgrade delivering FVM-EVM at the end of 2022. My proposal assumes that EOY is a reasonable target for the FVM team. If they are not projecting to be ready in that window, I would advocate for expanding nv17 scope somewhat. |
Beta Was this translation helpful? Give feedback.
-
|
This looks great, and mirrors the tracking that was being done on the governance side. At this point, it seems reasonable to confirm the technical scope of nv17 as follows:
The only discrepancy between this list and the one outlined by @anorth above is that there is no planned inclusion for FVM gas model updates. This follows previous guidance from the FVM team, but can be amended if necessary. Importantly, the above is merely a technical scope. All FIPs must still complete Last Call and be 'Accepted' in time for inclusion into the upgrade. Given this, the tentative timeline is likely:
Ideally, all FIPs will be accepted before any testing/code freeze. For now, we can estimate that all FIPs ought to be accepted by September 1. However, certain FIPs (particularly those for which acceptance is assumed) can complete Last Call up until the date of the calibnet freeze. For these FIPs, acceptance must happen by September 15 (tentative). Any FIP author who believes they need extra time beyond September 1 to complete Last Call should flag their needs in #fil-fips ASAP. |
Beta Was this translation helpful? Give feedback.
-
|
Apologies for catching up on this late! The Forest 🌲 team should be mostly fine with the above FIPs & the timeline. Just need to double check on FIP0044 Standard Message Authentication and FIPXXXX PoRep Security Policy. |
Beta Was this translation helpful? Give feedback.
-
Upgrade Name |
Beta Was this translation helpful? Give feedback.
-
|
Panda （just china Panda, in honor the China SP's ) |
Beta Was this translation helpful? Give feedback.
-
|
I like Candy! |
Beta Was this translation helpful? Give feedback.
-
|
Candy is too generic IMO. We usually used more specific names. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
Creating this async discussion for core devs to start to propose ntwk v17 upgrades scope - FIPs that should be considered to be accepted & finalized in network v17.
Creating two threads for discussion :
Beta Was this translation helpful? Give feedback.
All reactions