ERC20 개선을위한 375K 이유
EOS, BAT (Basic Attention Token) 및 Storj와 같은 ERC20 토큰 기반의 거물 인 경우 인터페이스 계약의 성공을 주장하기가 어렵습니다. Ethereum 커뮤니티는이 표준에 대한 지원을 분명히 모았습니다., & 개발자 커뮤니티와 금융 시장 모두 긍정적으로 반응하고 있습니다. 그러나 모든 성공에 대해 ERC20 표준은 그다지 중요하지 않은 버그를 생성했습니다.
ERC20 토큰 표준은 사용자가 ERC20을 준수하지 않는 토큰 주소로 ERC20 토큰을 보낼 수 있도록하여 최종 사용자의 금전적 손실을 초래합니다..
사용자가 ERC20 토큰을 인식하지 않는 Ethereum 계약에 ERC20 토큰을 보내면 사용자는 자신의 자금에 대한 액세스 권한을 영원히 잃게됩니다. 이 문제로 인해 현재 잠긴 자금은 정확히 몇 개입니까? 다시 말하지만, 사소한 금액은 아닙니다.
- 310,067 GNT Golem 계약에 갇혀 있음 (현재 약 $ 217K 가치).
- 242 명 Augur 계약에 갇혀 있음 (현재 약 $ 15K 가치).
- 814 DGD Digix DAO 계약에 갇혀 있음 (현재 약 $ 125K 가치).
- 14,506 1 차 FirstBlood 계약에 갇혀 있음 (현재 약 $ 12K 가치).
이것은이 계약에서 동결 된 ERC20 토큰의 무려 $ 370K 이상입니다.; ERC20 토큰 목록이 증가하고 있기 때문에이 숫자는 계약에서 동결 된 토큰의 총량을 보수적으로 과소 평가했을 가능성이 높습니다. 위의 목록은 결코 완전한 것이 아닙니다. 이들은 더 인기있는 ERC20 토큰 중 일부에 불과합니다..
위의 어떤 계약도 ERC20 토큰을받을 것으로 예상하지 않았습니다. 따라서 사용자가 이러한 주소로 토큰을 보낼 때 네트워크에서 거래를 확인합니다. 그러나 수신 계약은 토큰을 인식하지 못합니다. 이 토큰으로 무엇을해야하는지 알지 못해 자금이 영원히 잠 깁니다. 다시 말하지만, 토큰은 거부되지 않고 수신 계약에 의해 완전히 무시됩니다..
이러한 트랜잭션의 대부분은 최종 사용자가 이전 함수 (이전에 소개 된 자동 transferFrom 함수와 반대). ERC20은 두 가지 전송을 모두 사용합니다. & TransferFrom — 일부 최종 사용자가 Transfer를 사용하여 ERC20 토큰을 예상하지 않은 계약에 직접 전송하는 것으로 나타났습니다., & 따라서 들어오는 토큰을 인식하지 못합니다..
결국 이더 리움 커뮤니티의 몇몇 회원들은 새로운 ERC 토큰 표준을 요청하여이 문제를 정면으로 해결하기로 결정했습니다. GitHub에서이 새로운 토큰 표준의 발행 번호는 발행 번호 # 223입니다..
ERC223 제안
GitHub 사용자 Dexaran은 2017 년 3 월 5 일에이 토큰 대체 실패 문제를 해결하기 위해 새로운 ERC 표준 (ERC223)을 제안했습니다. 그의 GitHub issue # 223 새로운 토큰 제안에 대한 초록은 다음과 같습니다.
Dexaran의 토큰 제안은 분산 된 앱 사용자가 토큰을받을 준비가되지 않은 스마트 계약에 실수로 토큰을 보내는 것을 즉시 막기 위해 두 가지 핵심 기능을 구현합니다.
- ERC20 통합 이전 & TransferFrom 단일 기능 이전 세 개의 매개 변수가있는 함수 : (address _to, uint _value, bytes 데이터).
- 그만큼 전수 계약 (토큰을받는 경우), 절대로 필요한 것 포함 TokenFallBack 들어오는 토큰 유형을 처리하는 방법을 정확하게 정의하는 함수.
이전 & TransferFrom -> 이전
이 일반적인 문제에 기여하는 ERC20 표준의 핵심 부분은 최종 사용자가 전송에 사용 된 두 기능 중 하나를 실수로 사용할 수 있다는 사실입니다. & TransferFrom).
ERC223은 두 기능을 하나의 이전 함수.
ERC223을 사용하면 dapp 최종 사용자가 토큰을 어떤 이더 리움 주소는 계약이 지갑이든 계약이든 상관없이 동일한 전송 기능을 사용합니다. 여기서 논리는 사용자가 Transfer 함수를 트리거하는 옵션을 제거함으로써 또는 TransferFrom 함수를 단일 Transfer 함수로만 전환하면 최종 사용자가 더 이상 잘못된 함수를 사용할 가능성이 없습니다..
새로 제안 된 Transfer 함수는 세 개의 매개 변수 (이전에는 두 개만 허용됨)를 허용하며, 더 중요한 것은 수신 주소에서 TokenFallback 함수를 호출하는 것입니다. 세 개의 정의 된 매개 변수가 없으면 Transfer 함수가 컴파일되지 않습니다. TokenFallback 함수를 포함하는 수신 주소가 없으면 Transfer 함수 트랜잭션이 실패합니다. & 토큰이 전송되지 않습니다..
function tokenFallBack ()
이더 리움 개발에는 계약 수정자가 있습니다. 지불 가능 이더 리움을 받기위한 계약을 준비하는 데 사용됩니다. 이것은 계약이 이제 디지털 통화를 기대하고 있음을 의미합니다. 계약이 아니 지불 가능 수정자를 포함하면 전송 된 트랜잭션이 단순히 취소됩니다. & 반환되었습니다. 멋진 것은 없습니다. 이것은 Ethereum 101입니다..
ERC223 tokenFallback 함수에 대한 유사한 생각은 tokenFallback 함수가 x 토큰을 받기위한 계약을 준비하는 것이므로 지불 가능 수정자는 Ether를 받기위한 계약을 준비하는 것입니다..
이 표준에서 계약 개발자는 절대로 필요한 것 계약이 특정 토큰과 함께 작동하도록하려면 tokenFallback을 구현하십시오. 수신자가 비 계약 주소 인 경우 ERC223 토큰 트랜잭션은 현재 ERC20 토큰 전송과 마찬가지로 실행됩니다. 반면에 수신자가 계약 인 경우 ERC223 토큰 계약은 먼저 수신자 계약에서 tokenFallback을 호출하려고 시도합니다. tokenFallback 함수가 없으면 트랜잭션이 실패합니다..
ERC의 진화
ERC223의 초안 상태에도 불구하고 또 다른 ERC 표준 인 ERC 721이 등장합니다. ERC721은 대체 불가능 CryptoKitties, Decentraland 토지와 같은 자산, & 하루 부동산 자산 일 수도 있습니다. ERC 721 진행 상황은 여기에서 확인할 수 있습니다. https://github.com/ethereum/eips/issues/721
이더 리움 커뮤니티는 젊은 시절에 증가하는 새로운 개발자의 물결 앞에 올바른 표준을 적용하여 스마트 계약 플랫폼을 개선하는 데 매우 진지하다는 것을 보여줍니다. 느리지 만 확실하게 ERC 토큰 버그가 줄어들 것입니다. 그러면 질문이 최신 표준 규모가 될 수 있습니다.?
