eip: 4902
title: Decentralized Autonomous Access (DAA)
description: DAAs represent access to digital or physical things, with the ability to connect with entities seeking to use them
author: D Daniel eartho.offical@gmail.com
discussions-to: [DRAFT] ERC-4902: Decentralized Autonomous Access (DAA) by eartho-group · Pull Request #4902 · ethereum/EIPs · GitHub
status: Draft
type: Standards Track
category: ERC
created: 2022-03-22
requires: 20
Abstract
As humans, we are constantly seeking as much access to resources as possible, We also make access trades for our needs regularly, it can be for information, food, rides, content, hotels, jobs, and so on. The trade could be as simple as me looking for access to food and the other side looking for access to money.
Looking at our economy as an access trade, it appears that we are trading an access on things with every action we take. For example, when we buy a hamburger, actually we are purchasing the access to it created by the restaurant’s employees, who also trade in their resources and sell access to their time and energy to the owner of a restaurant, what called ‘job’.)
An access emerges from the abilities of actors to benefit from ‘things’.
The actors are divided into two groups: those who create the access and make it possible for it to be exchanged, and those who use it for their own purposes and needs.
A decentralized autonomous access (DAA), is an access represented by rules encoded as a computer program that is transparent, controlled by the actors and not influenced by a 3rd party entity, in other words, they are member-owned trade that do not have a centralized/controller middleman.
A DAA’s financial transaction record and program rules are maintained on a blockchain.
DAA is automatically managed by pre-accepted agreements called trust models
While ERC-721(NFT) created for “NFTs represent ownership over digital or physical assets.”,
ERC-DAA created for “DAAs represent an access over digital or physical things & resources, with the ability to connect with entities that seeking to use it”
Access Theory
Access theory attempts to describe in economics the trade between entities through an access.
We can represent every trade that exists between people using 1 abstract concept and fixed properties.
Motivation
Ownership is based on social consensus and relies on a third party to record and enforce it, it is nearly impossible to transition from the current economy to the web3 world, because that data cannot be shared and cannot be on-chain.
By changing our mindset from myth of “ownership, control, assets” to “access”, We are able to eliminate several issues such as the need for trust on the old registrations and records of the institutions.
Trading access is a convenient and cost-effective way to use resources without the financial, emotional, oracle issues, or social burdens that come with ownership.
Specification
-
Proofs represent the requirements that a given action must meet in order to connect to the access. - For instance, minbalance
-
Trust represent - The logic used to build trust between the two actors.
Trust model explained
Trust models are simply blockchain-stored programs that run under predefined conditions to build trust between DAA actors
When a connection between an access and a member begins to be established, the member should first accept the suggested terms, which are then managed by the trust models while the connection is active.
Trust Model Types
Trust1 - One time trust
Transferring the money at once (Buy something, or get one time access. - example: ticket to party)
Trust2 - Stream of trust by time
Every second portion of the money flows
Trust3 - Trust by stages
pre-defined number of stage that each one need to be approved again.
Trust4 - Start amount + deposit amount
Initial amount of money that go at start and then at the end approval required to transfer the all amount.
Trust5 - 3rd party operator
Agreed money transferred to operator that manage it by it self, probably will be with commission and insurance service.
How it works by stages?
- Minting DAA - define the behaviors and configs you would wish like
Someone is trying to connect to your access
2. Proof stage - the user should have all the request requirements in order to get connected with the DAA
3. Trust stage - starts the trust process between the actors and according to the agreed configs and terms
Every DAA composed from the following properties:
-
holder, address - An address of the main holder of the access
-
accessibility, uint8 - private , protected , public - Defines if the DAA can be accessed by no-one/owner permission/everyone
-
fungibleConnections, boolean - Determine if a connection can be changed or not. In case of false once a connection has made, It cannot be changed or be canceled.
-
maxConnections, uint32 - The max connections an access can have
-
connections, map(uint8 => ConnectedEntity) - Entities that are connected with the access
struct ConnectedEntity { uint8 role; uint8 status; uint256 startTime; }
- configs, mapping(uint8 => mapping(uint8 => Config)) configs
- Defines the required proofs according to specific role.
So for example, role of guest will require minimum balance of 100$ in his account and role of friend will required 0$.
- Defines the required proofs according to specific role.
So for example, role of guest will require trust of first pay of 5$ and deposit of 50$ and role of friend will required 0$ of both.
Entity can interact with DAA with following API
interface IERC4902Connection {
/**
* Access id can be any kind of tokenid - ERC(ERC-721)
* Creates the connection for given 'accessId', 'account' and 'role'.
* It depends on the role whether it allows it or not, based on the proofs and authorization * configuration.
**/
function connect(
uint256 accessId,
address account,
uint8 role,
uint256 startTime
) external returns (bool);
/**
* Closing the connection for 'account' with a given access
**/
function disconnect(uint256 accessId, address account)
external
returns (bool);
/**
* Checking if an account has any kind of access
* @return bool
**/
function isConnected(uint256 accessId, address account)
external
returns (bool);
/**
* Returns all account that has connected with a given access
* Temporary function, in future services will map connected and disconnected events
**/
function getConnections(uint256 accessId)
external
returns (uint256[] memory);
/**
* Emitted when a new connection to access has been created
*/
event Connected(address indexed from, address indexed to, uint256 accessId);
/**
* Emitted when an account disconnected from an access.
*/
event Disconnected(
address indexed from,
address indexed to,
uint256 accessId
);
}
interface IERC4902Trust {
/**
* Return the terms of the access by a role
**/
function terms(uint256 accessId, uint8 role)
external
view
returns (string memory);
/**
* Checks if an account has the requirements in order to get connected with the access.
* The requirements can be defined by the holder of the access by role
**/
function proof(
uint256 accessId,
address account,
uint8 role
) external view returns (bool);
/**
* Starting the trust process for a given accessId and account
**/
function trust(uint256 accessId, address account) external;
}
interface IERC4902Metadata {
/**
* @dev Returns the Uniform Resource Identifier (URI) for `tokenId` token.
*/
function getMetadataUri(uint256 accessId)
external
view
returns (string memory uri);
/**
* @dev Set the Uniform Resource Identifier (URI) for `tokenId` token.
*/
function setMetadataUri(uint256 accessId, string memory value)
external
returns (bool);
}
Rationale
Its the very first draft.
There is consideration to split this into proof, trust , access instead of being in one contract.
For me its more a philosfical considoration that im wondering if an access can be represented without this things based on “An access emerges from the abilities of actors to benefit from ‘things’.”
I hope people will help me to achieve that conclusions in the future.
Backwards Compatibility
There is some desire to made it possible to take existing ERC-721 tokens and made them an access too.
Test Cases
Test cases for an implementation are mandatory for EIPs that are affecting consensus changes. If the test suite is too large to reasonably be included inline, then consider adding it as one or more files in ../assets/eip-####/.
Reference Implementation
In private repo for now, so will be open
Security Considerations
Every action should be accepted by the actors.
Copyright
Copyright and related rights waived via CC0.
Eartho Group, Daniel, Tel Aviv