search

sablier-labs / v2-core

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

Package tethering #808

Open PaulRBerg opened 5 months ago

PaulRBerg commented 5 months ago

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

andreivladbrg commented 5 months ago

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

PaulRBerg commented 5 months ago

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

andreivladbrg commented 5 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 5 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 5 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 5 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 5 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 5 months ago

@smol-ninja sounds good.

andreivladbrg commented 4 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 4 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 4 months ago

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

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

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

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

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

smol-ninja commented 2 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 2 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 2 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 2 months ago

i am not in favor of this

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

andreivladbrg commented 2 months ago

great, thanks for confirming