Replies: 1 comment
-
|
Proposal was created: |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Overview
This proposal introduces a set of targeted improvements to the TAC network as part of the v1.0.4 upgrade. The changes include activation of a new EVM precompile for ed25519 signature verification and a security fix in the staking precompile's authorization logic.
These are the PRs in the TAC GitHub repositories reflecting the changes:
Upgrade timeline
Updating process
If this discussion will not raise critical doubts from validators and the public audience over the course of the next few days, and there will be a positive outcome from the TAC Foundation, we will submit an on-chain expedited governance proposal on April 10. The validators will have 3.5 days to vote. Validators must update their TAC nodes to v1.0.4 after the network reaches block 17530000(approx. April 14, 12:00 UTC).
Technical implementation
The proposed upgrade includes 2 changes:
Ed25519 Precompile
A new precompile is being activated at address
0x00000000000000000000000000000000000008f3. It allows EVM smart contracts to verify ed25519 signatures directly on-chain, without relying on off-chain proofs or custom Solidity implementations.Interface
The precompile exposes a single function:
publicKey— 32-byte ed25519 public keysignature— ed25519 signature as a fixed 2-element array ofbytes32(R and S halves)message— arbitrary byte payload that was signedtrueif the signature is valid,falseotherwiseBenefits
Authz Fix in Staking Precompile
A hot-fix is applied to the staking precompile's authorization handling. Previously, a missing or incorrectly scoped authorization check could allow a caller to exercise delegation management rights they had not explicitly been granted.
What was fixed
x/authzgrant before executing any state-changing staking operation on behalf of an origin addressImpact
No changes to validator or delegator workflows are required. Existing
x/authzgrants remain valid. Contracts that relied on the unchecked path will need to obtain a proper grant to continue operating.Beta Was this translation helpful? Give feedback.
All reactions