PDP service contract whitelist #545
Conversation
* ServiceAuth and NullAuth * fix --------- Co-authored-by: zenground0 <[email protected]>
* Add sql migration function to enable public service with dummy key * Fix typo --------- Co-authored-by: zenground0 <[email protected]>
Co-authored-by: zenground0 <[email protected]>
Co-authored-by: zenground0 <[email protected]>
* Look in pdp piecerefs to check for actual readiness * fix --------- Co-authored-by: zenground0 <[email protected]>
Co-authored-by: zenground0 <[email protected]>
Co-authored-by: zenground0 <[email protected]>
…h) (#530) * feat(pdp): add transaction tracking for root additions - Add Location header to root addition response with tx hash - Add GET /proof-sets/{id}/roots/added/{txHash} endpoint for status checks - Implement handleGetProofSetRoot for retrieving root details - Return confirmed root IDs after transaction confirmation * fix(pdp): use lowercase transaction hashes consistently in database operations * fix(pdp): retain root addition records to prevent 404s on status queries Previously, pdp_proofset_root_adds records were deleted after processing, causing clients to receive 404 errors when querying transaction status after successful root additions. This created a poor UX as clients couldn't verify transaction outcomes if they queried too late. This change aligns root addition tracking with proof set creation by: - Adding roots_added column to mark processed records instead of deleting - Updating watcher to UPDATE instead of DELETE when processing completes - Including roots_added status in API response for client visibility The fix ensures transaction status remains queryable indefinitely while maintaining backward compatibility. Existing records will be processed normally with roots_added=FALSE by default. API enhancement: /pdp/proof-sets/{id}/roots/added/{txHash} now includes "rootsAdded" field indicating if roots were fully processed. * fix(pdp): extra checks to make sure the db entries are consistent * fix(pdp): address review feedback
|
cc @rvagg |
|
|
||
| // Check if the recordkeeper is in the whitelist | ||
| for _, allowed := range allowedList { | ||
| if recordKeeper == allowed { |
There was a problem hiding this comment.
Do you know if common.Address is going to be happy with case-insensitive forms of the address? Should we just lower-case all addresses to avoid any issues with case sensitivity and not demand the user provide the correct validation form?
There was a problem hiding this comment.
Good question. After looking into it the answer is that case insensitivity is handled correctly.
Tracing through common.Address everything relies in a straightforward way on golang stdlib hex encode decode. Stdlib reverse lookup from ascii code to hex value is here: https://cs.opensource.google/go/go/+/refs/tags/go1.24.4:src/encoding/hex/hex.go;l=25 and you can see capital letters are treated correctly.
I see where you're coming from but since it only applies to the public service I am ok with leaving it as a build constant like the existing verifier. Merging synapse back to main will require some conceptual merging of the public service construct and we can revisit this question then as part of that. |
This provides some protection for curio PDP operators running publically accessible PDP services. Only the pandora PDP service contract is allowed upon proofset creation over the publically available PDP service.
The whitelist is network dependent -- only calibnet specified as pandora only launched on calibnet.