A lucky contract - ERC-777

background

The ERC-777 token comes from the original EIP (Ethereum Improvement Recommendation) - https://eips.ethereum.org/EIPS/eip-777, written by Jacques Dafflon, Jordi Baylina and Thomas Shababi. The 777 in the name doesn't really make any sense, just because the current index of githubissues is generated. However, you can't deny that this is a number that allows developers everywhere to have a soft spot. The initial motivation for this proposal was to provide a transaction with less friction than the current ERC-20 specification. If you work long hours in this area, you will know that trading between individuals who maintain their keys and wallets is easy. You also know that once you deviate from this simple use case, things become more difficult.

How ERC-777 will stop injuries The

following are some of the common things I have experienced while working with Ethereum and how the ERC-777 specification will help people.

Third Party Expenses - Carrier

ERC-20

In a typical ERC-20 scenario, if I want to approve a third party account or smart contract to use my account's token, I will need two transactions to perform a single transfer. I need to call to approve the spender and the amount of money they are authorized to pay, and the smart contract or address will need to execute the transaction. The problem is not that I have to approve the account, but that I have to give it a spending limit and make sure it is always enough for me to trade.

The ERC-777

ERC-777 standard hopes to address third-party spending issues by introducing the concept of an operator. Operators are a well-known concept in service architecture because they are specific rights accounts that perform specific tasks. For ERC-777 tokens, there are two types of carriers - the regular operator and the default operator regular operator is an address that allows tokens to be sent and burned on behalf of another address. The default carrier is the address that allows all token holders to send and burn tokens.

Natural gas consumption solution

A common problem when using a wallet on an exchange or dApp is the natural gas fee for the payment transaction. Users don't want or need to care which block blocks their transactions, as long as it's reasonable speed. Using "operator" allows you to manage consumption costs as a dApp or exchange owner to maintain the user experience.

Ownership and Expense

One of the advantages of the ERC20 standard is that there are many tokens that are compatible with it. This provides a good ecosystem foundation for its development and user adoption. However, when you own an Ethereum wallet, each address constitutes an account with a unique public/private key. If you have thousands of users on an exchange, but you don't have a private key for that user's funds, how do you provide it? Settlement? The operator will be a good use case because it does not really constitute ownership, but will allow you to transfer funds for transaction settlement. It's important to note that addresses can add/remove carriers at any time, so this is a tricky business.

The use of the ERC-820 contract

operator was eventually enabled by another contract, ERC-820. This contract acts as a general, ownerless registry where any account/address can check the tokens they are trying to send and whether the destination to which they are sent can receive/manage these types of tokens. This seems to be an improvement of ERC-223, which is designed to help prevent users from sending tokens to incompatible smart contracts. In a normal ERC-20 use case, the sender must send an "approved" transaction before any PokerCointoken can be sent to the SureThing smart contract. In this case, the PokerCoin Token (ERC-777) developer only needs to register their token with the ERC-820 and declare that it is compatible with the PokerCoin contract. Any attempt to send an unregistered pokercoin to an ERC-820 contract will fail.

Another promise of the ERC-777 standard is Hook. They are still a bit mysterious to me, but essentially they will allow developers to implement blocks of code that are executed before/after the execution of the transaction in order to send notifications via events, additional input, block addresses or other process-related items.

Summarizing

the combination of operator and ERC-820 means that we know where to send tokens and who to use tokens. As a user of our fictional dApp, I can safely set the PokerCoin contract address to "My Carrier" and I can send these tokens based on the developer's registration on the PokerRegistry ERC-820 Smart Contract. The only destination is the PokerCoin contract.