| fip | title | author | discussions-to | status | type | created | replaces |
|---|---|---|---|---|---|---|---|
0044 |
Standard Authentication Method for Actors |
Aayush Rajasekaran (@arajasek), Alex North (@anorth) |
Draft |
Technical (Interface) |
2022-08-02 |
FIP-OO35 |
Change history
- February 2023: Added boolean return value to AuthenticateMessage
The Filecoin protocol has entities called "actors" that can be involved in computation on the Filecoin blockchain. There are various different kinds of actors; among the most common are accounts and multisigs. With the planned introduction of the Filecoin Virtual Machine, there will be many new kinds of user-defined actors. Unfortunately, today, the only kind of actors that can "authenticate" a piece of data are account actors -- they do so through a signature validation. This FIP is the starting point to evolve a convention by which any actor can verify such authenticity. It simply proposes adding a special "authenticate" message that actors can choose to implement. If they do implement such a method, it can be used by other actors to authenticate pieces of data.
There is a need for arbitrary actors to be able to verify (to other actors) that they have approved of a piece of data. This need will become more pressing with the Filecoin Virtual Machine.
This FIP proposes adding an AuthenticateMessage method that any actor can choose to implement.
This method can be called by any other actor to verify the authenticity of a piece of data. This is a small change to the existing actors, and allows for user-defined actors to flexibly implement this method according to their needs.
Concretely, we add this method to the built-in Account actor, and have the built-in Storage Market and Payment Channel actors invoke this method,
in lieu of validating signatures directly.
We want any actors, including user-defined actors, to be able to authenticate arbitrary data. If we don't have this ability, we will need to engineer around it in painful ways.
The proposed FIP-0035
is a concrete example. It seeks to allow user-defined actors to serve as storage clients in the built-in Storage Market actor.
In order to enable this, it proposes adding several new methods and data types in order to work around the
inability of user-defined actors to authenticate data.
It will be infeasible to modify the builtin-actors themselves every time we want to be able to authenticate some new kind of information, and doing so will require more total messages to be landing on the Filecoin blockchain. Instead, a flexible, universal approach for actors to authenicate data would be preferred.
We propose adding the following method to the built-in Account Actor.
This method can then be the blueprint for other builtin actors (eg. the multisig actor),
as well as a template for user-defined actors.
/// Authenticates whether the provided input is valid for the provided message.
/// Returns false if the authentication is invalid.
/// Any non-zero exit code must also be interpreted as authentication failure.
pub fn authenticate_message(params: AuthenticateMessageParams) -> Result<bool, ActorError>
The params to this method is a wrapper over the message and signature to validate:
pub struct AuthenticateMessageParams {
pub authorization: Vec<u8>,
pub message: Vec<u8>,
}
Further, we propose modifying the built-in Storage Market and Payment Channel to call this method instead of validating signatures directly.
The idea is to create a flexible, lightweight endpoint that actors can expose to callers that might want to
validate its authorization. Some actors will have very obvious implementations: the account actor simply
performs a signature validation, while an m/n multisig need only perform m signature validations.
Other actors might opt for creative implementations of such authorization based on their needs. Yet
others can choose not to support this endpoint at all -- the Filecoin protocol's singleton builtin-actors
such as the Storage Power Actor, the System Actor, the Cron Actor, etc. will likely choose to omit this method.
In order for this method to function as a standard for future actors, it needs a standardized invocation pattern.
In the current dispatch model based on method numbers, that would be a standardized method number for authenticate_message methods. This FIP does not propose adopting a standard method number, preferring to rely on a new standardized calling convention, such as FRC-0042 instead.
A non-empty return value is specified in order to avoid a no-op implementation of this method inadvertently being interpreted as a successful message authentication.
Introducing new methods to the builtin-actors needs a network upgrade, but otherwise breaks no backwards compatibility.
Proposed test cases include:
- that the
authenticate_messagemethod on account actors can be called and succeeds with valid input - that the
authenticate_messagemethod on account actors can be called, but fails with invalid input - that storage deals can be made with the changes to the
StorageMarketActor
We need to be careful with the security of the authenticate_message implementations of the
builtin-actors. User-defined contracts are free to implement these methods as they see fit.
This FIP only proposes adding the authenticate_message method to the account actor, which
simply invokes the signature validation syscall.
This proposal is generally well-aligned with the incentives of the network. It can be considered as a simpler replacement for FIP-0035, with the only drawback being that this proposal as currently written does not allow for the existing built-in multisig actor to be a storage client.
This proposal is the first step towards enabling non-account actors to function as clients for storage deals, which is a major product improvement. Furthermore, it enables future innovation that relies on the ability of non-account actors to authenticate data as approved.
Partial implementation here
Copyright and related rights waived via CC0.