or
or
By clicking below, you agree to our terms of service.
New to HackMD? Sign up
Syntax | Example | Reference | |
---|---|---|---|
# Header | Header | 基本排版 | |
- Unordered List |
|
||
1. Ordered List |
|
||
- [ ] Todo List |
|
||
> Blockquote | Blockquote |
||
**Bold font** | Bold font | ||
*Italics font* | Italics font | ||
~~Strikethrough~~ | |||
19^th^ | 19th | ||
H~2~O | H2O | ||
++Inserted text++ | Inserted text | ||
==Marked text== | Marked text | ||
[link text](https:// "title") | Link | ||
 | Image | ||
`Code` | Code |
在筆記中貼入程式碼 | |
```javascript var i = 0; ``` |
|
||
:smile: | ![]() |
Emoji list | |
{%youtube youtube_id %} | Externals | ||
$L^aT_eX$ | LaTeX | ||
:::info This is a alert area. ::: |
This is a alert area. |
On a scale of 0-10, how likely is it that you would recommend HackMD to your friends, family or business associates?
Please give us some advice and help us improve HackMD.
Do you want to remove this version name and description?
Syncing
xxxxxxxxxx
Abstract
The proposed standard extends ERC-1271 to support historical signature validation. This creates a standard interface for onchain and offchain consumption of ERC-1271-based signatures that may have been valid in the past but no longer correspond to a current EIP-1271
isValidSignature
function.Motivation
While externally owned account (EOA) signatures are perpetually valid, smart contract accounts (SCAs) can support updates to their signature validation logic, which means offchain EIP-1271 signatures that appear valid at a point in time are not guaranteed to be valid in the future. This inconsistency poses challenges for applications relying on these signatures to prove validity of attestations, statements, intents, or authorizations over time, particularly when interacting with SCAs that support rotating signers.
Specification
Functions
wasValidSignature
_timestamp
: Timestamp at which the signature needs to be validated._hash
: Hash of the data to be signed._signature
: Signature byte array associated with the hash._data
: Arbitrary extra data used for verification.0x1626ba7e
if the signature is verified as valid.Solidity interface
Rationale
The introduction of historical validation mechanisms in EIP-1271 addresses a critical gap in the evolving landscape of SCAs and their interaction with digital signatures. As SCAs are updated over time, the logic governing signature validation can change, potentially rendering previously valid signatures invalid. This inconsistency poses challenges in scenarios where historical messages and signatures must remain verifiable indefinitely.
Design Decisions
_timestamp
parameter, this function provides the flexibility needed for applications to confirm the validity of a signature that may not otherwise appear as valid. This is particularly important for SCA compatibility for attestation and other offchain-signature-based workflows, where the signature may not need to be verified by the chain until some future point in time, and the ability to retroactively invalidate signatures in this manner may be undesirable. The rest of the function's signature matches EIP-1271.Backwards Compatibility
This EIP is designed to be fully compatible with EIP-1271 and does not affect existing implementations that do not require historical signature validation.
Reference Implementation
While this simple implementation requires data to be posted directly onchain to ensure its validity at a point in time, more opinionated flavors may take advantage of the extra _data parameter to allow verification via more bespoke patterns such as by providing proofs of existence.
Security Considerations
Care must be taken to ensure that the update mechanism for the signature validation logic is secure against unauthorized changes. Additionally, the storage method chosen must be optimized to prevent excessive gas costs associated with storing historical data.