URC Registration

[GalRogozinski]

What is the URC?

The Universal Registry Contract (URC) allows validators to register for preconfirmation services that adhere to the eth-fabric standard. This enables them, as block proposers, to earn additional profits by making off-chain promises to include certain transactions.

What operations can validators perform with the URC?

All operations are listed here. They are:
register, unregister, optIntoSlasher, optOutOfSlasher

Register

Sends a transaction that links an ETH address to a validator's SignedRegistration (an ETH address signed using a BLS key). The data is serialized into JSON. This transaction also includes some collateral.

Unregister

Sends a transaction to unregister a validator. It must be signed by the original owner and include the RegistrationRoot that was returned during the register step.

OptIntoSlasher

Sends a transaction to opt the validator into a slasher. Requires:

• REGISTRY_ADDRESS
• REGISTRATION_ROOT
• SLASHER
• COMMITTER (may differ from owner)

OptOutOfSlasher

Sends a transaction to opt out of a slasher. Requires:

• REGISTRY_ADDRESS
• REGISTRATION_ROOT
• SLASHER

---

What operations should be performed as part of DVT?

We need to produce SignedRegistration signatures. This can be achieved by leveraging our existing validatorRegistrationDuty flow.

We should consider two implementation paths:

1. A backwards-compatible approach
2. A fork-based approach, which provides better UX as the feature would activate network-wide at a designated epoch. A fork would primarily be required to introduce changes to the MessageValidation logic.

There are two key concerns to address:

---

1. Triggering the Signature Aggregation

a. No-Fork – Use Ethereum event listeners (the existing method).
It may be feasible to reuse the ValidatorRegistrator validation logic without introducing a new message validation rule. However, this approach has limitations if ValidatorRegistration is called multiple times for different purposes on the same validator.

b. Fork – Introduce a node RPC endpoint that listens for off-chain requests signed by the validator cluster owner.
These requests are then propagated via our p2p network. We must ensure that some nodes in our UI are available for RPC and connected to all topics. A fork is required here to enforce new message validation rules.

---

2. Returning the SignedRegistration to the Validator Owner

After the signing ceremony, we must return the SignedRegistrations to the validator owner so they can interact with the URC contract. Two approaches are possible:

a. No-Fork – Operators upload the result to IPFS.
This requires them to either run an IPFS node or use a public IPFS RPC gateway. For our purposes, the RPC option should suffice and is currently free.

b. Fork – Operators gossip the result back to peers.
This should ideally occur on the committee topic to avoid noise on unrelated nodes. Any node listening on the topic can act as a server to serve the result. This approach requires adding a new message validation rule.

---

❓ Is it fine The SignedRegistration isn't encrypted?

Yes, we sign over the owner address to avoid attacks.

---

Conclusion

For the fastest deployment path, choose:
Option 1a (No-Fork + Event Listening)
Option 2a (IPFS result delivery)

Option 1b can be considered if gas optimization for users is a priority, even at the cost of protocol complexity.
Option 2b is suitable if we want to avoid external dependencies or if operators are reluctant to interact with external services.

[GalRogozinski]

For the IPFS option:

Each operator can create an IPNS (IP Name Space) and have it displayed on the UI, so users can locate their files.

[GalRogozinski]

Another option offered by @liorrutenberg is to do this all via DKG, since validators that never used DKG should have a copy of their key.