search

sablier-labs / v2-core

⏳ Core smart contracts of the Sablier V2 token distribution protocol
https://sablier.com
Other
314 stars 48 forks source link

Package tethering #808

Open PaulRBerg opened 10 months ago

PaulRBerg commented 10 months ago

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

andreivladbrg commented 10 months ago

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

PaulRBerg commented 10 months ago

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

andreivladbrg commented 10 months ago

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
PaulRBerg commented 10 months ago

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.

smol-ninja commented 10 months ago

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.

PaulRBerg commented 10 months ago

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.

smol-ninja commented 10 months ago

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):

@andreivladbrg do you have any comment on this?

PaulRBerg commented 10 months ago

@smol-ninja sounds good.

andreivladbrg commented 10 months ago

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

PaulRBerg commented 10 months ago

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.

smol-ninja commented 10 months ago

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

PaulRBerg commented 10 months ago

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".

smol-ninja commented 10 months ago

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

PaulRBerg commented 10 months ago

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.

smol-ninja commented 9 months ago

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 commented 8 months ago

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?

PaulRBerg commented 8 months ago

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

smol-ninja commented 8 months ago

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.

PaulRBerg commented 8 months ago

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.

andreivladbrg commented 7 months ago

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

smol-ninja commented 7 months ago

i am not in favor of this

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

andreivladbrg commented 7 months ago

great, thanks for confirming

smol-ninja commented 4 months ago

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

PaulRBerg commented 4 months ago

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

smol-ninja commented 4 months ago

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

andreivladbrg commented 4 months ago

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

smol-ninja commented 4 months ago

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?

andreivladbrg commented 4 months ago

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

PaulRBerg commented 1 week ago

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