Abstract
Upgrade the Entropy contracts on testnet to version 2.0.
Rationale
The v2.0 upgrade will introduce significant quality of life improvements for all Entropy users.
Description
Entropy version 2.0 introduces several developer experience upgrades around callbacks, including configurable gas limits and better error reporting. It also improves the event definition and simplifies the user-facing API.
PRs
main ← entropy_error2
opened 04:59PM - 02 Apr 25 UTC
## Summary
Currently, the Entropy keeper cannot invoke a callback if the unde… rlying callback fails. This creates confusion for users, who can't distinguish between "the keeper is offline" and "my callback code reverts".
This change creates a failure flow for callbacks that allows the keeper's transaction to succeed while explicitly reporting a failure of the underlying callback. Requests with failing callbacks remain on the blockchain and can be re-invoked by users. This feature allows users to gracefully recover in cases where the callback fails for transient reasons. (In the future, it will also allow recovery in the case where the callback uses too much gas.)
Note that this PR doesn't cover the case where the callback uses too much gas. I will send a follow-up PR for that.
## How has this been tested?
- [x] Current tests cover my changes
- [x] Added new tests
- [ ] Manually tested the code
main ← entropy_error3
opened 02:40PM - 04 Apr 25 UTC
## Summary
Follow up to the last PR around allowing providers to mark on-chai… n callbacks as failed. The previous PR covers cases where the contract manually reverts. This PR covers the case where the callback runs out of gas.
This PR gives each callback a gas limit which is stored in the on-chain struct. Providers can set a default gas limit, or users can manually specify a different gas limit when making a request. We mark callbacks as failed if they revert with an out-of-gas error *and* the transaction had enough gas to forward -- there are some EVM nuances here that we need to be careful about. See inline comments for details.
## Rationale
Explicitly marking on-chain requests as failed will make the state transitions of entropy much clearer to end users.
## How has this been tested?
- [x] Current tests cover my changes
- [x] Added new tests
- [ ] Manually tested the code
main ← entropy_error6
opened 06:53PM - 24 Apr 25 UTC
## Summary
Bring back the original EntropyStructs definitions and move the ne… w structs to EntropyStructsV2. Use the old EntropyStructs in events to maintain the selectors.
## Rationale
The last few Entropy PRs have added fields to the contract structs, which were backward compatible with the storage. However, these changes change the selectors of Events, which breaks the public interface of the contract that is used by Fortuna to identify requests. This PR fixes the public interface so the selectors aren't changed.
## How has this been tested?
- [ ] Current tests cover my changes
- [ ] Added new tests
- [x] Manually tested the code
I checked out an old version of the code and computed selectors using `forge selectors list` then compared with the new version.
main ← entropy_error8
opened 04:02PM - 25 Apr 25 UTC
## Summary
As the description says -- it turns out that you can't decode the … old struct data with the new struct format. This restores the old method signatures and adds new methods for retrieving the new versions of the structs.
I don't love that we have new methods here for retrieving requests / providers, but that's the only way I see to ensure that all users of the contract continue working.
## How has this been tested?
- [x] Current tests cover my changes
- [ ] Added new tests
- [x] Manually tested the code
I tested getting both a request and a provider from an old contract.
main ← entropy_error10
opened 06:43PM - 25 Apr 25 UTC
## Summary
Add a new set of EntropyEvents to improve on the previous spec. Sp… ecifically, add indexing for the salient attributes, stop depending on struct definitions (which, if changed, break the event signature), and add dummy bytes for future extensibility.
In the process, I have omitted events for code paths that we are going to kill off (like the old pull flow).
## How has this been tested?
- [x] Current tests cover my changes
- [x] Added new tests
- [ ] Manually tested the code
main ← entropy_error11
opened 03:57PM - 28 Apr 25 UTC
## Summary
As the PR title says
## Rationale
Showing the gas limit and … usage will be useful for users to see if their callback is using too much gas, and also to adjust their usage.
## How has this been tested?
- [x] Current tests cover my changes
- [x] Added new tests
- [ ] Manually tested the code
main ← entropy_error12
opened 06:49PM - 28 Apr 25 UTC
## Summary
Update the expectEmit calls to test all topics and data. These wer… e previously only testing the data field.
This is going to conflict with the other outstanding PR but I'll resolve that depending on which gets approved first.
## How has this been tested?
- [ ] Current tests cover my changes
- [ ] Added new tests
- [ ] Manually tested the code
main ← entropy_error13
opened 07:57PM - 28 Apr 25 UTC
## Summary
Add a set of `requestV2` methods that give callers optionality on … specifying providers etc. I think we get a set of questions like "what's a provider" or "what's userRandomNumber" which originate from the confusing function signatures in the user interface.
I'm not sure why we didn't do this in the first place -- i think for some reason we thought we couldn't override method names. It works though so I think we go for it.
I think we may want to pull out some of these methods into a separate solidity interface to make it easier for users of entropy to see the methods they want to call as well. If you're onboard with the interface changes, then I can do that next.
## Rationale
This should make it easier for developers to use entropy -- just call `requestV2()` and get a callback.
## How has this been tested?
- [ ] Current tests cover my changes
- [ ] Added new tests
- [ ] Manually tested the code
main ← entropy_error15
opened 02:15PM - 01 May 25 UTC
## Summary
Split out the V2 functionality into a separate file. The intention… is that developers can interact exclusively with the IEntropyV2 interface. This interface hides internal methods for providers etc that users don't need to know about. Meanwhile, we retain the IEntropy interface (which has the old functions + provider functions + inherits the V2 functions) as the full interface the contract implements.
## Rationale
These changes should make it easier for users to identify the functionality they need
## How has this been tested?
- [ ] Current tests cover my changes
- [ ] Added new tests
- [ ] Manually tested the code
main ← entropy_error16
opened 07:32PM - 08 May 25 UTC
## Summary
As the title says. Track gas usage and emit it in the event.
##… Rationale
I previously omitted gas tracking in this recovery flow (which is identical to the old callback flow). However, I realized tracking gas will be useful here -- if a user's callback fails and they recover it, they probably want to know how much gas it used so they can set the gas limit better next time.
## How has this been tested?
- [ ] Current tests cover my changes
- [ ] Added new tests
- [ ] Manually tested the code
main ← entropy_error17
opened 04:14PM - 12 May 25 UTC
## Summary
Three minor changes:
1. rename "providerRandomNumber" and "userRa… ndomNumber" to xContribution for clarity.
2. emit these contributions in the new EventsV2 revealed event (so users can generate a retry call in forge from the event, without hitting the fortuna API)
3. update docs around how the protocol works and security assumptions (this was a comment from AR)
## How has this been tested?
- [x] Current tests cover my changes
- [x] Added new tests
- [ ] Manually tested the code
main ← entropy_error19
opened 10:06PM - 12 May 25 UTC
## Summary
I'm making this 2.0 to agree with all of our comms around this. I'… m skipping version 1 but whatever.
## Rationale
## How has this been tested?
- [ ] Current tests cover my changes
- [ ] Added new tests
- [ ] Manually tested the code
Implementation
Proposal: Pyth Network
Make sure you have node-js, forge and jq installed.nvm from here . Install node-js 22 (nvm install 22; nvm use 22)here here
Clone the pyth-crosschain repo (git clone https://github.com/pyth-network/pyth-crosschain.git). Go to the pyth-crosschain directory and run the following command: pnpm i
Get the on-chain implementation code digest by going to the contract_manager directory and running npx ts-node scripts/check_proposal.ts --cluster mainnet-beta --proposal <proposal id>
Get the source code digest by going to the target_chains/ethereum/contracts directory angd running pnpm exec truffle compile --all && cat build/contracts/EntropyUpgradable.json | jq -r .deployedBytecode | tr -d '\r\n' | cast keccak. The expected hash is 0x73c503a468a8dd2ee816211dafca5892a82e819ade17a21ad3b84622b3be919c
Check the hash digest from the on-chain implementation (from step 3) matches the hash digest from the source code (from step 4).
2 Likes