v2-core icon indicating copy to clipboard operation
v2-core copied to clipboard

Package tethering

Open PaulRBerg opened this issue 2 years ago • 28 comments

As discussed in https://github.com/sablier-labs/company-discussions/discussions/25

  • [x] Move all the V2 Periphery contracts here
  • [x] Update all stale references (e.g. turn "V2 Core" into "V2 Lockup")
  • [x] Remove the "V2" from the contract names (note: for ASCII, you can use the "Dark with Shadow" font on this tool)
  • [ ] Don't forget about the related stuff, e.g. the Wikis
  • [ ] Rename this repo to lockup

PaulRBerg avatar Jan 30 '24 11:01 PaulRBerg

In advance, I want to mention that this change will likely take a longer amount of time.

andreivladbrg avatar Jan 30 '24 11:01 andreivladbrg

Yep. That's why I've marked it as effort: epic.

PaulRBerg avatar Jan 30 '24 11:01 PaulRBerg

just noticed this:

Rename this repo to v2-lockup

wasn't the idea to also remove "v2" from the repo name? i would suggest lockup-contracts, maybe?

from here:

AVB: image

PRB:

image

andreivladbrg avatar Jan 30 '24 15:01 andreivladbrg

Oh shoot, you're right @andreivladbrg.

The repo should be renamed to evm-lockup or sablier-lockup.

I would go with the latter, though I'm on the fence about it. Which one do you like more? Cc @smol-ninja.

PaulRBerg avatar Jan 30 '24 18:01 PaulRBerg

I am more inclined towards calling it sablier-lockup. My rationale is that Sablier may not necessarily be compatible with different types of zkEVMs, such as type 3 and type 4 [^1] without modifying some parts of it. Even though they are not in practice yet and not very popular, calling it evm-lockup wouldn't do justice to the name.


Since this is going to be an epic level of effort and likely to take longer time (as Andrei correctly pointed out), there could be a huge number of conflicts between changes introduced by this and other PRs raised during the same period, should we split it into multiple issues for a smooth transition from current architecture to PacTet architecture?

[^1]: zkEVMs are also EVMs.

smol-ninja avatar Jan 31 '24 08:01 smol-ninja

That's a good point, @smol-ninja, but after more rumination on this, I think we should go with evm-lockup.

  1. Even if type-3/4 zkEVMs are not full-blown EVMs, they are still fundamentally EVMs. evm-lockup would be a good first approximation.
  2. If we use sablier-lockup, how would we name a non-EVM Lockup implementation? solana-lockup? Naming it like that would break the consistency in naming, i.e., one repo would start with the project name ("Sablier"), the other with the blockchain name ("Solana").

WDYT?

should we split it into multiple issues for a smooth transition from current architecture to PacTet architecture?

I am open to that, but I would still prefer to keep this "parent" issue to track all the other "child" issues. We could replace the task list in the OP with references to the other isuses.

PaulRBerg avatar Jan 31 '24 10:01 PaulRBerg

Fair point about evm-lockup. I agree with both of your arguments.

I am open to that, but I would still prefer to keep this "parent" issue to track all the other "child" issues. We could replace the task list in the OP with references to the other issues.

Yes, thats what I had in my mind. We can split into the following sub-issues (suggestions welcome):

  • Move all the V2 Periphery contracts here and integrate with the core repo
  • Remove "V2" from the contracts
  • Update ERC721 name to Sablier Lockup Linear v1.0.1 NFT (in case of Lockup Linear)
  • Rename this repo to evm-lockup and refactor the contract names
    • Update all references in the code such as function names, variables etc.
    • Update markdown guidelines
  • Update Wikis
  • Update Sablier docs

@andreivladbrg do you have any comment on this?

smol-ninja avatar Jan 31 '24 11:01 smol-ninja

@smol-ninja sounds good.

PaulRBerg avatar Jan 31 '24 11:01 PaulRBerg

Move all the V2 Periphery contracts here and integrate with the core repo Rename this repo to evm-lockup and refactor the contract names Update all references in the code such as function names, variables etc. Update markdown guidelines

between these two, we should remove "V2" from the contracts

one other thing bad with the sablier-lockup name is that it would be redundant to have "sablier" twice in the github URL: sablier-labs/sablier-lockup

andreivladbrg avatar Jan 31 '24 14:01 andreivladbrg

we should remove "V2" from the contracts

yeah, that should be another issue

one other thing bad with the sablier-lockup name is that it would be redundant to have "sablier" twice in the github URL: sablier-labs/sablier-lockup

That's not bad, actually. The name "sablier" would appear on more computers.

PaulRBerg avatar Jan 31 '24 15:01 PaulRBerg

As discussed on Slack, this will be picked after major refactoring and LockupTranched contracts are finished.

smol-ninja avatar Feb 02 '24 06:02 smol-ninja

Another implication of PacTet is that we will have to update the name of our NFT collections on Etherscan.

For instance, this collection should be renamed from "Sablier V2 Lockup Linear NFT" to "Sablier Lockup Linear v1.0.1 NFT".

PaulRBerg avatar Feb 02 '24 10:02 PaulRBerg

The name is not related to Etherscan. It's ERC721 metadata set up in our core contracts.

smol-ninja avatar Feb 02 '24 12:02 smol-ninja

The name is not related to Etherscan

Actually, it's also related to Etherscan. The NFT collection has to be manually listed (which is what I did a while ago).

but yes you're right that we also have to update the metadata in the Solidity code.

PaulRBerg avatar Feb 02 '24 12:02 PaulRBerg

Original issue https://github.com/sablier-labs/v2-core/issues/820.

The task is to adjust the description generated in the NFT descriptor to account for the package tethering, i.e., say LockupLinear v1.1.2 instead of Sablier V2:

https://github.com/sablier-labs/v2-core/blob/d5aea835dfe32b6cffa1c8cb40a7ba458f4ab5ee/src/SablierV2NFTDescriptor.sol#L261-L279

smol-ninja avatar Feb 12 '24 12:02 smol-ninja

Since open-ended and core are going to share the same periphery contracts, shouldn't we include open-ended repo into this as well? Ofc, we can choose to not include it but what are your thoughts on this?

smol-ninja avatar Apr 05 '24 10:04 smol-ninja

Do you mean include open-ended in the repo currently called v2-core?

PaulRBerg avatar Apr 05 '24 11:04 PaulRBerg

Yes thats what I meant, or we build separate periphery contracts for the open-ended, i.e. v2-lockup contains core and periphery required for lockup product and open-ended repo contains core and periphery required for open-ended.

smol-ninja avatar Apr 05 '24 11:04 smol-ninja

Got it.

I need to review open-ended before I am able to properly comment on this. But my instinct is to keep them separated.

PaulRBerg avatar Apr 05 '24 12:04 PaulRBerg

Since open-ended and core are going to share the same periphery contracts

this is not correct, this is why we have renamed the batch contract to BatchLockup

shouldn't we include open-ended repo into this as well? Ofc, we can choose to not include it but what are your thoughts on this?

i am not in favor of this, since the repo name would contain lockup and the package versions are not synced

andreivladbrg avatar Apr 18 '24 13:04 andreivladbrg

i am not in favor of this

Me neither. I also think we should keep OE separate from lockup repo.

smol-ninja avatar Apr 18 '24 15:04 smol-ninja

great, thanks for confirming

andreivladbrg avatar Apr 18 '24 15:04 andreivladbrg

@PaulRBerg should we rename SablierNFTDescriptor to LockupNFTDescriptor or SablierLockupNFTDescriptor given that NFT Descriptor for Flow would be separate?

smol-ninja avatar Jul 31 '24 15:07 smol-ninja

The jury is still out if it will be separate. But let's go with LockupNFTDescriptor for now.

PaulRBerg avatar Jul 31 '24 15:07 PaulRBerg

The refactor PR has been merged so now we can move ahead with changing the repo name.

smol-ninja avatar Aug 01 '24 23:08 smol-ninja

The refactor PR has been merged so now we can move ahead with changing the repo name.

wait, i think we shouldn't rename it until staging is merged to main - i.e. when we release the next version

andreivladbrg avatar Aug 02 '24 08:08 andreivladbrg

I understand your point—it would be odd to have two repos tied to the current release: lockup and v2-periphery.

While writing this, I thought, what if we archive both v2-core and v2-periphery as they are, and then fork v2-core (including all branches) into a new lockup repo? What do you think?

smol-ninja avatar Aug 02 '24 09:08 smol-ninja

I understand your point—it would be odd to have two repos tied to the current release: lockup and v2-periphery.

While writing this, I thought, what if we archive both v2-core and v2-periphery as they are, and then fork v2-core (including all branches) into a new lockup repo? What do you think?

hmm, interesting idea, not sure yet what to say

my point is to not rush with the decision

andreivladbrg avatar Aug 02 '24 09:08 andreivladbrg

I suggest renaming this repo to lockup instead of creating a separate one. The rationale is thus:

  • We would lose the 310+ stars
  • We would lose the connectivity enabled by the historical backlinks (on X, Telegram, etc.)

PaulRBerg avatar Nov 20 '24 15:11 PaulRBerg

I have refactored the Wiki, there were some commands that no longer apply such as related to createWithRange.

https://github.com/sablier-labs/lockup/wiki

smol-ninja avatar Jan 29 '25 16:01 smol-ninja