Improvements needed on the event-based features

[ylembachar]

• The decryption key endpoint has not been updated, and does not return decryption keys for event-based identities. (High) (for now return all decryption keys for identity, later allow for identity per eon) ==> Implement GetDecryptionKey endpoint for event based decryption triggers #86

• The decrypt commitment should also be adjusted (High)

• Manual padding needed for non‑indexed, non‑uint256 args: left‑pad bytes to 32 bytes (High)

• Check whether dynamic types (string, bytes, arrays) are supported for non‑indexed arguments: https://github.com/shutter-network/shutter-api/blob/main/internal/usecase/eventtrigger.go#L221 (Dynamic types are considered like static types here starting at a certain offset with a fixed length when their encoding is different, the head contains an offset to where the length and actual content is) (Medium) - if not supported, document for now

• Update the contract / potentially rolling shutter to check for duplicates:

• allow same identity registration as long as the expiration block is higher than the previous one (only API since only API using contract)

• if a user submits a registration with different event triggers, the second would take precedence over the previous registration -> Change primary key to eon, identity here: https://github.com/shutter-network/rolling-shutter/blob/main/rolling-shutter/keyperimpl/shutterservice/database/sql/migrations/V2_event_based_triggers.sql#L13C18-L13C46 as well as the update on conflict query

• what if we want to allow different ttls with the same identity
  See comment here: Add endpoints for event based decryption triggers #79 (comment) (Medium)

• About the ttl / expiration block, we would be returning 0 while we wait for the tx to be mined, could be updated to pending perhaps but 0 could also mean the same as pending
  See comment here: Add endpoints for event based decryption triggers #79 (comment) (Low)

• Add a documentation note to let the user know that they need to check for the transaction hash success to ensure the registration has succeeded / check endpoint behavior when transaction does not succeed (Medium)

• The API can still be deployed even if the event registry contract isn’t deployed; event endpoints will just fail at runtime with a 500 error. Nice‑to‑have: add a feature flag to enable/disable event triggers while still serving endpoints. If the contract isn’t deployed, return a 503 Service Unavailable error. Not required for the upcoming deployment. (Low)

• Design improvement: Revisit GetDataForEncryption endpoint #83

• Add intended use for /get_data_for_encryption (Low)

• Add a prefix for both time-based and event-based endpoints that would redirect to the same backend endpoint if needed (e.g. /time/register_identity versus /event/register_identity) - check if there is a version in the path (Medium)

[ylembachar]

Testing on Chiado

• use any ERC20 and make sure it works (OK)
• deploy contract with different triggers and make sure they work (todo)
• behavior of ttl
• extending the ttl