feature: eth-vrf

[makramkd]

feature set:

• add a subscription owner contract that allows users to migrate across coordinators
• add a new "v2.5" contract that supports link and native billing. this has breaks the abi in small ways, but nothing too major.
• the v2.5 contract also informs the consumer how much they paid by writing to storage. optionally, we can call back into their contract again.
• add a new base consumer contract to account for v2.5 behavior

other changes:

• refactor the vrf package to have v1, v2 subpackages (among others) to ease the addition of new code
• for v2, to support v2 and v2.5, refactor the coordinator interface to a common set of behaviors that are implemented in v2 and v2.5 under the hood, due to the abi breakage
• update the vrf job spec to specify which v2 version to use, valid inputs are "V2" or "V2_5"

still todo:

• add native billing behavior in v2 listener
• add integration tests for native billing behavior
• add integration tests for subscription owner contract, migration, etc.
• add sample contracts that pass costs to the end user
• add unit tests for new contracts (forge?)

[github-actions]

Go solidity wrappers are out-of-date, regenerate them via the make go-solidity-wrappers command

[jinhoonbang]

Took a pass through the contract changes and it looks good to me. Will do another pass through tests soon. Some high level comments:

1. Should we add some logic to incentivize LINK over native payment? It could be a configurable parameter that charges extra for native payments if both payment options are available.
2. Should we consider globally unique subscription ID? might result in a more consistent and intuitive user experience across versions. That being said, I think the migration logic where new subscription ID is created on the new coordiantor should work too.
3. s_requestPayments seems like a nice win! :)

[github-actions]

Go solidity wrappers are out-of-date, regenerate them via the make go-solidity-wrappers command

[makramkd]

Should we add some logic to incentivize LINK over native payment? It could be a configurable parameter that charges extra for native payments if both payment options are available.

As of now there are two different premiums - LINK and Native. You could reduce the LINK premium to incentivize.

Should we consider globally unique subscription ID? might result in a more consistent and intuitive user experience across versions. That being said, I think the migration logic where new subscription ID is created on the new coordiantor should work too.

Maybe, but I think it'd be a wash. It's easier to remember a shorter subscription ID than one that is a uint256. For the UI, we'd have to scope things by coordinator instead of just /<network>/<subid> but that doesn't seem like too big a lift. Open to discussing more.

s_requestPayments seems like a nice win! :)

That's still not final. Another option would be to callback again into the user contract with a small gas limit (say 25k) and let them do what they want with the value, but I feel like this is slightly cleaner.

In general I'd like to reduce scope creep; slight improvements are fine but the less major changes the better.

[jinhoonbang]

Another option would be to callback again into the user contract with a small gas limit (say 25k) and let them do what they want with the value, but I feel like this is slightly cleaner.

Alternatively, payment amount can be part of rawFulfillRandomWords()

[makramkd]

Alternatively, payment amount can be part of rawFulfillRandomWords()

Unfortunately it can't be because you have to execute the callback to figure out how much gas it uses exactly.

[github-actions]

Go solidity wrappers are out-of-date, regenerate them via the make go-solidity-wrappers command

[github-actions]

Go solidity wrappers are out-of-date, regenerate them via the make go-solidity-wrappers command

[github-actions]

Go solidity wrappers are out-of-date, regenerate them via the make go-solidity-wrappers command

[cl-sonarqube-production]

SonarQube Quality Gate

0 Bugs
0 Vulnerabilities
0 Security Hotspots
9 Code Smells

84.9% Coverage
2.2% Duplication