feat(lazer/contracts/evm): Add fees for verification #2163
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
2 Skipped Deployments
|
| @@ -6,6 +6,7 @@ import "@openzeppelin/contracts-upgradeable/access/OwnableUpgradeable.sol"; | |||
|
|
|||
| contract PythLazer is OwnableUpgradeable, UUPSUpgradeable { | |||
| TrustedSignerInfo[2] public trustedSigners; | |||
| uint256 public verification_fee = 0.00001 ether; | |||
There was a problem hiding this comment.
Not sure what is an appropriate fee. Changing this value does not impact the tests (Unless the fee is a fractional wei which I don't think is possible?) so we can just change this to whatever we want.
There was a problem hiding this comment.
Is this 1 wei? I thought 1 eth was 10^18 wei
| address bob = makeAddr("bob"); | ||
| vm.deal(bob, 1 ether); | ||
|
|
||
| // Alice provides appropriate fee |
There was a problem hiding this comment.
I decided to just bunch these all together. I can also make them separate unit tests too, but I liked the idea of making more than one call on an account and confirming their balance changes as expected.
| @@ -6,6 +6,7 @@ import "@openzeppelin/contracts-upgradeable/access/OwnableUpgradeable.sol"; | |||
|
|
|||
| contract PythLazer is OwnableUpgradeable, UUPSUpgradeable { | |||
| TrustedSignerInfo[2] public trustedSigners; | |||
There was a problem hiding this comment.
The storage is incremental in EVM. I recommend we leave room for more signers here so we can add more signers. A better thing to do is to transition from having a list of signers to a map of addressSigner to expiresAt.
There was a problem hiding this comment.
Just an FYI for this, by replacing it with a mapping, we seem to incur some costs:
- We take up semi-random storage slots for hashed items in the mapping instead of a linear sequence of slots. This means collisions become possible, though very unlikely.
- Scanning through the items in the mapping are basically impossible, especially considering gas fees. This means migrating the mapping in any way would be pretty difficult since modifying the struct changes the slots taken up by each item, and making a new map would be tricky since it would be hard to transfer the data over.
I would rather increase the size to a comfortable size like 100, rather than change to a map which we would have issues working with. This is based on what I've learned so far, so I could be wrong on some of these things. Please do let me know if something is wrong in my considerations above.
No description provided.