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
@@ -42,7 +47,7 @@ as well as a template for user-defined actors.
42
47
43
48
```
44
49
/// Authenticates whether the provided authorization is valid for the provided message.
45
-
/// Errors if the authentication is invalid.
50
+
/// Errors with USR_ILLEGAL_ARGUMENT if the authentication is invalid.
@@ -89,8 +94,8 @@ simply invokes the signature validation syscall.
89
94
## Incentive Considerations
90
95
91
96
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.
97
+
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.
98
+
It would be trivial to add a similar `verify_authorization` method to the built-in multisig actor, though.
0 commit comments