Open
Conversation
Reviewer @rvagg @ZenGround0 Fixes a few things with the deploy-warm-storage-implementation-only script #### Context Toward FilOzone#346 #### Changes * remove unused FILBEAM_CONTROLLER_ADDRESS * use existing SIGNATURE_VERIFICATION_LIB_ADDRESS if provided * fix `--libraries` arg * use `-f 0x000000000000000000000000000000000000000000` with `cast call` to skip password prompt
…ilOzone#349) # Fixes FilOzone#347 - Replaced the filfox to blockscout as the default block explorer --------- Co-authored-by: Phi <orjan.roren@gmail.com>
…lOzone#356) ## Summary This PR covers the `ServiceProviderRegistry` side of [FS FilOzone#355](FilOzone#355) by adopting the `announcePlannedUpgrade` pattern already used by `FilecoinWarmStorageService`. PDPVerifier changes are implemented in a separate PR in [`pdp`](FilOzone/pdp#234) and are not included here. ## Changes ### ServiceProviderRegistry contract - Add `PlannedUpgrade` struct and `nextUpgrade` storage field - Add `UpgradeAnnounced(PlannedUpgrade)` event - Implement: - `announcePlannedUpgrade(PlannedUpgrade plannedUpgrade)` — owner-only, validates code size and `afterEpoch > block.number`, stores the plan and emits `UpgradeAnnounced` - `getNextUpgrade() returns (address nextImplementation, uint96 afterEpoch)` — exposes the planned upgrade via the proxy - Update `_authorizeUpgrade(address newImplementation)` to: - Require `newImplementation == nextUpgrade.nextImplementation` - Require `block.number >= nextUpgrade.afterEpoch` - Clear the stored plan on successful upgrade - Update `migrate(string newVersion)` to: - `public onlyProxy onlyOwner reinitializer(2)` - Emit `ContractUpgraded(newVersion, ERC1967Utils.getImplementation())` ### Upgrade scripts - Add `tools/announce-planned-upgrade-registry.sh` - Announces a planned upgrade for a `ServiceProviderRegistry` proxy using `announcePlannedUpgrade((address,uint96))` - Add `tools/upgrade-registry.sh` - Reads `getNextUpgrade()` from the registry proxy - Verifies the planned implementation and `afterEpoch` - Calls `upgradeToAndCall(address,bytes)` with `migrate(string)` and the desired version - Verifies the final implementation using the standard ERC-1967 implementation slot (`0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc`) ### Tests - Extend `ServiceProviderRegistryTest` to cover: - `testAnnouncePlannedUpgrade` — happy-path announce and gated upgrade flow - `testAnnouncePlannedUpgradeOnlyOwner` — only the owner can announce - `testAnnouncePlannedUpgradeInvalidImplementation` — revert on non-contract implementation - `testAnnouncePlannedUpgradeInvalidEpoch` — revert when `afterEpoch <= block.number` - `testOnlyOwnerCanUpgrade` — validates that: - Non-owner upgrades revert - Owner can upgrade after a valid announcement and epoch gating Closes : FilOzone#355
…ilOzone#364) ## Summary This PR implements automatic deployment address management using `deployments.json`, addressing issue FilOzone#354. Scripts now automatically load and update contract addresses from a JSON file keyed by chain-id, eliminating the need for manual environment variable management. ## Changes - **Added `tools/deployments.sh`**: Shared script with functions to: - Load deployment addresses from `deployments.json` for a given chain-id - Update addresses in JSON after deployment - Track metadata (commit hash, deployment timestamp) - Handle missing chains gracefully - **Created `deployments.json`**: JSON structure for storing addresses organized by chain-id - **Updated deployment scripts** to use the shared system: - `deploy-all-warm-storage.sh` - `deploy-session-key-registry.sh` - `deploy-registry-calibnet.sh` - `deploy-warm-storage-calibnet.sh` - `upgrade.sh` - `upgrade-registry.sh` - **Updated documentation**: Added section to `tools/README.md` explaining the system ## Features - Addresses automatically loaded from JSON (no need to set env vars) - Addresses automatically updated after deployment - Chain-id based organization (e.g., `jq '.["314"]' deployments.json`) - Environment variables can still override JSON values - Control flags: `SKIP_LOAD_DEPLOYMENTS` and `SKIP_UPDATE_DEPLOYMENTS` - Metadata tracking for commit hash and deployment timestamp ## Usage # Addresses are automatically loaded from deployments.json ./tools/deploy-all-warm-storage.sh # Query addresses jq '.["314159"].WARM_STORAGE_PROXY_ADDRESS' deployments.json # Skip loading/updating if needed SKIP_LOAD_DEPLOYMENTS=true ./tools/deploy-all-warm-storage.sh## Testing - Tested with calibnet deployment - Verified addresses are correctly loaded and updated - Confirmed backward compatibility (env vars still work) Closes FilOzone#354 --------- Co-authored-by: Phi-rjan <orjan.roren@gmail.com>
Supersedes FilOzone#246. We are GA-launching with static rail pricing, so documenting that in a SPEC.md --------- Co-authored-by: Rod Vagg <rod@vagg.org>
…e#372) Remove challengeWindow(), getChallengesPerProof(), and getMaxProvingPeriod() from external API. Use getPDPConfig() instead per IPDPProvingSchedule interface. Closes: FilOzone#336
Co-authored-by: Rod Vagg <rod@vagg.org>
…#377) Block dataSetDeleted until settledUpTo >= endEpoch, preventing SPs from deleting datasets before clients can settle. Allow settlement to advance past unproven periods once their deadlines pass (with zero payment). Closes: FilOzone#375
…e#381) * Payment rate updates now only occur during piecesAdded or when pieces are removed in nextProvingPeriod. * Owner pricing changes now only apply on next piece operation. * RailRateUpdated events only emit when rates actually change. Prompted by 2 things: * We rely on `FilecoinPayV1#modifyRailPayment` being a noop when we're not changing rate. But it's not free, and we know the two points at which the rate changes, so why not use that? The side effect here is as above, owner pricing changes don't take effect until the user modifies the data set in some way. * Noticing that `RailRateUpdated` is emitted every time that `updatePaymentRates` gets called, even if there are no rate changes, and it gets called every `nextProvingPeriod`, so we have one of these events per proving period.
…Ozone#388) BREAKING change because it renames keys here but they are very inconsistent and confusing and the PDP ones don't even show you what the proxy is. --- I had to go use this today and was a bit frustrated it was less useful than I imagined. @rjan90 I got `SIGNATURE_VERIFICATION_LIB_ADDRESS` off a message in Slack from you for calibnet but had to go hunting on the chain for the mainnet one, I'm pretty sure that's it by the bytecode match but you might just want to see if you have a record of that being the right address for mainnet.
Closes FilOzone#382 Reviewer @rvagg ProviderIdSet is an Ownable arrayset of provider ids. It uses less space than a bitset if the selected providerIds are sparse. It uses 1/16 as much space as an [OpenZeppelin EnumerableSet](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/structs/EnumerableSet.sol). If we want to reuse this data structure in another smart contract, it can be converted into a library, but I do not do that here. #### Interface * `getProviderIds` * `containsProviderId` * `addProviderId` * `removeProviderId` #### Changes * add ProviderIdSet * test ProviderIdSet * add deployment script * deploy on mainnet and testnet
Reviewer @rvagg @ZenGround0 This is needed for wagmi in synapse. #### Changes * add ProviderIdSet abi
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
7 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Particularly interested in receiving these:
Note: these commits ARE NOT currently in a released version of the upstream.