You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Filecoin protocol has entities called "actors" that can be involved in computation on the Filecoin blockchain.
15
15
There are various different kinds of actors; among the most common are accounts and multisigs.
16
16
With [the planned introduction of the Filecoin Virtual Machine](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0030.md), there will be many new kinds of user-defined actors.
17
-
Unfortunately, today, the only kind of actors that can be asked to verify whether they have authorized a piece of data are account actors -- they do so through a signature validation.
18
-
This FIP is the starting point to evolve a convention by which any actor can verify such authorization. It simply proposes adding a special "authorize" message that actors can choose to implement.
19
-
If they do so, it can be used by other actors to validate their authorization of data.
17
+
Unfortunately, today, the only kind of actors that can "authenticate" a piece of data are account actors -- they do so through a signature validation.
18
+
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.
19
+
If they do implement such a method, it can be used by other actors to authenticate pieces of data.
20
20
21
21
## Abstract
22
22
23
-
There is a need for arbitrary actors to be able to authorize (to other actors) that they have approved of a piece of data. This need will become more pressing with the Filecoin Virtual Machine.
24
-
This FIP proposes adding an `Authorize` message that any actor can choose to implement. This message can be called by any other actor to verify whether the "authorizer"
25
-
approves 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.
23
+
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.
24
+
This FIP proposes adding an `Authenticate` method that any actor can choose to implement.
25
+
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.
26
+
Concretely, we add this method to the built-in `Account` actor, and have the `Storage Market` actor invoke this method,
27
+
in lieu of validating signatures directly.
26
28
27
29
## Change Motivation
28
30
29
-
We want any actors, including user-defined actors, to be able to confirm that they have authorized some data.
30
-
If we don't have this ability, we will need to engineer around it in painful ways. The proposed [FIP-0035](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0035.md)
31
-
is a concrete example; it proposes adding several new methods and data types in order to enable
32
-
user-defined actors to serve as clients for storage deals.
31
+
We want any actors, including user-defined actors, to be able to authenticate arbitrary data.
32
+
If we don't have this ability, we will need to engineer around it in painful ways.
33
33
34
-
It will be infeasible to modify the builtin-actors themselves every time we want to be able to authorize some new kind of information, and doing so will require more total messages
35
-
to be landing on the Filecoin blockchain. Instead, a flexible, universal approach for actors to authorize data would be preferred.
34
+
The proposed [FIP-0035](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0035.md)
35
+
is a concrete example. It seeks to allow user-defined actors to serve as storage clients in the built-in `Storage Market` actor.
36
+
In order to enable this, it proposes adding several new methods and data types in order to work around the
37
+
inability of user-defined actors to authenticate data.
38
+
39
+
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
40
+
to be landing on the Filecoin blockchain. Instead, a flexible, universal approach for actors to authenicate data would be preferred.
36
41
37
42
## Specification
38
43
@@ -41,15 +46,15 @@ This method can then be the blueprint for other builtin actors (eg. the multisig
41
46
as well as a template for user-defined actors.
42
47
43
48
```
44
-
/// Authenticates whether the provided authorization is valid for the provided message.
The params to this method is a wrapper over the message and signature to validate:
50
55
51
56
```
52
-
pub struct VerifyAuthorizationParams {
57
+
pub struct AuthenticateMessageParams {
53
58
pub authorization: Vec<u8>,
54
59
pub message: Vec<u8>,
55
60
}
@@ -66,6 +71,9 @@ Other actors might opt for creative implementations of such authorization based
66
71
others can choose not to support this endpoint at all -- the Filecoin protocol's singleton builtin-actors
67
72
such as the Storage Power Actor, the System Actor, the Cron Actor, etc. will likely choose to omit this method.
68
73
74
+
In order for this method to function as a standard for future actors, it needs a standardized invocation pattern.
75
+
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](https://github.com/filecoin-project/FIPs/blob/master/FRCs/frc-0042.md) instead.
76
+
69
77
## Backwards Compatibility
70
78
71
79
Introducing new methods to the builtin-actors needs a network upgrade, but otherwise breaks no backwards compatibility.
@@ -74,29 +82,28 @@ Introducing new methods to the builtin-actors needs a network upgrade, but other
74
82
75
83
Proposed test cases include:
76
84
77
-
- that the `verify_authorization` method on account actors can be called and succeeds with valid input
78
-
- that the `verify_authorization` method on account actors can be called, but fails with invalid input
85
+
- that the `authenticate_message` method on account actors can be called and succeeds with valid input
86
+
- that the `authenticate_message` method on account actors can be called, but fails with invalid input
79
87
- that storage deals can be made with the changes to the `StorageMarketActor`
80
88
81
89
## Security Considerations
82
90
83
-
We need to be careful with the security of the `verify_authorization` implementations of the
91
+
We need to be careful with the security of the `authenticate_message` implementations of the
84
92
builtin-actors. User-defined contracts are free to implement these methods as they see fit.
85
93
86
-
This FIP only proposes adding the `verify_authorization` method to the account actor, which
94
+
This FIP only proposes adding the `authenticate_message` method to the account actor, which
87
95
simply invokes the signature validation syscall.
88
96
89
97
## Incentive Considerations
90
98
91
99
This proposal is generally well-aligned with the incentives of the network. It can be considered
92
-
as a simpler replacement for FIP-0035, with the only drawback being that this proposal as currently written does not allow for multisigs to be storage clients. It would be trivial
93
-
to add a similar `verify_authorization` method to the multisig actor, though.
100
+
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.
94
101
95
102
## Product Considerations
96
103
97
104
This proposal is the first step towards enabling non-account actors to function as clients for
98
105
storage deals, which is a major product improvement. Furthermore, it enables future innovation
99
-
that relies on the ability of non-account actors to authorize data as approved.
106
+
that relies on the ability of non-account actors to authenticate data as approved.
0 commit comments