추상적인
보조 제목
이 기사는 표준 ERC721 프로토콜을 중심으로 Mint, safeMint, transfer 등이 자산 관리를 구현하는 방법을 설명하고 코드를 해석하여 이더리움 데이터 체인의 보안 설계 및 비용 구성을 이해합니다.
디렉토리 개요
디렉토리 개요
1. 소위 NFT 자산은 무엇입니까?
텍스트
텍스트
텍스트
5. 이더리움 스토리지는 얼마나 비쌉니까?
보조 제목
객체 지향
연구 개발 - 장벽 없이 읽을 수 있고 절묘한 계약 설계를 이해할 수 있습니다.
비 RD - 나열된 코드를 이해하지 못할 수 있지만 표준 프로토콜의 설계 아이디어는 이해할 수 있습니다.
첫 번째 레벨 제목
opensea에서는 각 NFT에 고유 번호가 있음을 알 수 있습니다.
예를 들어 azuki 시리즈의 No.4132 페이지의 세부 정보 열에서 계약 주소, ID 번호, 배포된 퍼블릭 체인 및 기타 정보를 볼 수 있으며 속성 열은 다양한 속성을 가진 설정입니다. 및 해당 희귀도(Non- Azuki 자체는 가지고 있지만 Opensea 통합에 의해 계산됨).
보조 제목
그리고 소스 코드(여기서 ERC721 표준 라이브러리 openzepplin 코드 사용)를 다시 살펴보면 프로그램이 두 개의 전역 사전 유형 변수를 기록하고 주소를 또는 현재 소유자가 보유한 총 NFT 수를 _balances로 기록합니다.
그리고 ERC721은 혁신적으로 변수 _owners에 주소에 해당하는 ID를 부여하기 때문에 FT(동질성)와 NFT(비동질성)의 차이를 구분하여 ERC20 전용 _balances로 주소와 잔액을 관리합니다.
첫 번째 레벨 제목
2.1 민트 작동 방식Netflix의 NFT가 web2의 비즈니스 보안을 잊을 때
Mint는 이전 Love Death Machine NFT와 같이 각 NFT의 생성 과정인 캐스팅을 의미합니다.
Netflix의 NFT가 web2의 비즈니스 보안을 잊을 때
Mint는 NFT의 자산 인증서를 획득했습니다.
소스 코드에서 볼 수 있듯이 Mint는 주로 보안 판단을 내립니다.
판단 2: 이 거래소에서 운영하는 NFTID가 존재하지 않는지 확인
최종 코드가 하는 일은 다음과 같습니다.
연산 1: 이전된 주소가 보유한 총 _balances 수에 1을 더합니다.
판단 1: 입금 주소가 0x00이 아닌지 확인(블랙홀 주소는 입금 불가, 입금 시 자산 손실 발생)
작업 2: 해당 NFTID의 소유자를 이전된 주소로 수정
작업 3: 트랜잭션이 완료되면 방출 이벤트가 전송되어 오프체인이 이 트랜잭션의 데이터를 모니터링할 수 있습니다.
중간에 있는 _beforeTokenTransfer와 _afterTokenTransfer는 가상 함수로 표준 프로토콜을 수정하지 않고 프로젝트 측에서 특정 논리 코드를 추가하는 데 표준으로 사용됩니다.
2.2 safeMint가 더 안전한 이유
safeMint는 안전한 캐스팅을 의미하며, 코드 구현에서 보면 MInt 자체도 호출하는 것을 알 수 있지만 ERC165 표준에 속하는 _checkOnERC721Received 판단을 추가로 추가한 것으로, 이체 연산이 완료된 후 상대방을 판단하는 것과 같다. 주소가 블랙홀 주소(즉, 트랜잭션 NFT 작업을 시작할 수 없는 주소)인지 여부는 전송 대상이 컨트랙트 주소이고 컨트랙트에 미리 설정된 전송 기능이 없는 경우를 방지하기 위한 것입니다. 양도할 수 없는 자산으로 인해 영구적인 손실이 발생합니다.https://eips.ethereum.org/EIPS/eip-165
2.3 ERC165는 자산이 블랙홀로 전송되는 것을 어떻게 방지합니까?
디자인의 원래 의도는 다음과 같습니다.
컨트랙트의 인터페이스를 표준화하자는 제안이다.프로그래밍 문법에서 interface는 인터페이스를 의미한다.그 안에 정의된 함수는 구현할 수 없고 함수 이름의 해당 매개변수만 넣는다.프로그램이 복잡할 때, 디렉토리와 동일하며 일반적으로 내가 가진 것을 다른 사람에게 알려줍니다.
그러나 인터페이스의 작성 방식은 각각의 장단점을 가지고 있으며, 이름에 따라 매개변수의 종류가 정의되고 존재 여부도 다릅니다.
따라서 이 제안은 최종적으로 인터페이스의 식별 규칙을 표준화한 ERC165 표준을 형성했습니다.
사용 프로세스는 다음과 같습니다.
STEP 1 supportsInterface 기능이 있는지 확인하고 165 표준을 준수합니다.
(PS: IERC721Receiver.sol 확장 패키지를 도입하여 계약에 NFT 수신 및 전송 기능을 구현하도록 하십시오)
텍스트
표준 프로토콜 설계에는 두 가지 시나리오에서 사용되는 두 가지 전송 방법인 transfer 및 transferFrom이 있습니다.
transfer Transfer: 지갑이 보유한 NFTID를 지정된 주소로 전송하기 위해 사용자가 호출
다음과 비교하십시오.
transferFrom Transfer from: 특정 조직에 의해 호출되며 사용자는 먼저 특정 주소를 인증해야 전송 권한을 갖습니다.
다음과 비교하십시오.
이체는 현금 거래이며, 본인 주머니의 돈으로 지불
transferFrom은 코드를 스캔하여 금액을 공제하고 상점은 사용자가 소액 원천징수 권한을 열었는지 여부에 따라 공제를 신청합니다.
다음으로 예상치 못한 세부 정보가 있을 수 있는 코드를 살펴보겠습니다.
3.1 전송 방법
그는 현재 트랜잭션의 당사자가 이 NFTID의 소유자인지 여부를 감지하고 NFT가 0x00 주소로 전송되는 것을 제한합니다. 다음으로 발신 주소와 발신 주소의 잔액을 새로 고치고 _balances 전역 변수를 수정하고 _owners를 재설정하여 이 NFTID의 소유자 주소를 로 변경합니다.
다음은 보호 세부 정보입니다. 먼저 _approve(address(0), tokenId);를 실행하여 과거 승인을 삭제합니다. 이러한 단계가 없으면 자산 이전이 완료되지만 NFTID의 이전 승인은 여전히 존재합니다. 생각 주의하여:
3.2 transferFrom 작동 방식
여기서 트랜잭션의 특성은 _safeTransfer를 호출하므로 핵심 논리는 필수 부분입니다.
여기서 중요한 세부 사항은 다음과 같습니다. _msgSender() 이것은 openzepplin의 표준 라이브러리 Context.sol에 있는 메서드입니다.
사실 현재 트랜잭션의 발신자 주소를 얻기 위한 것이지만 여기서는 msg.sender를 직접 사용하는 대신 encapsulated 버전을 사용합니다.
따라서 중간에 있는 일부 계약은 도서관과 유사하게 이러한 특수한 상황을 고려해야 합니다.
나머지 판단은 이해하기 쉽고 반복되지 않는 승인 기록이 있는지 여부를 결정하는 것입니다.
첫 번째 레벨 제목
4. 체인에 저장할 수 있는 다른 데이터는 무엇입니까?
거래 링크를 읽은 후 실제로 많은 신입생들이 놀랐습니다.내가 구입한 NFT에는 귀속 주소가 나를 가리키는 ID가 하나만 있어 고유성을 달성했습니다. 그래도 희소성 정보는 어디있나요? 내 NFT 이미지 자체는 어디에 있습니까?
ERC721과 관련된 메타데이터 확장 IERC721Metadata.sol입니다.
원하는 것은 무엇이든 넣을 수 있지만 프로젝트 당사자는 종종 가장 기본적인 ID+IPFS 주소만 체인에 저장합니다.
이전 Etherscan 튜토리얼 방법을 통해 일부 프로젝트 데이터를 살펴볼 수 있습니까?
Azuki의 계약 주소: 0xed5af388653567af2f388e6224dc7c4b3241c544
최근 등장한 Metaverse 프로젝트인 Metaverse land sandbox와 **Decentraland는 물론 작년의 불 같은 **Axie Infinity의 경우 체인에 저장된 기본 메타데이터는 ID+URL뿐입니다.
미러와 같은 것들은 저렴하고 높은 저장 공간을 위해 특별히 설계되었으며 일반적으로 블록은 이더리움의 약 1000배인 30M에서 시작합니다.
첫 번째 레벨 제목
5. 이더리움 스토리지는 얼마나 비쌉니까?
이 기사가 조금 더 어려운 부분이 있습니다. 소스 코드에서 온체인 스토리지의 비용 구성 및 금액 환산을 분석해 봅시다.
실행 프로세스에 따라 비용 발생에는 두 가지 측면이 있습니다.
사용자가 트랜잭션을 시작하면 체인에 기록할 데이터가 매개 변수로 전달되며 그 크기는 비용입니다.
트랜잭션은 계약 코드를 실행하고 EVM은 수정 및 사용에 따라 소비되는 가스 비용을 계산합니다.
5.1 거래 개시 비용
트랜잭션 데이터 크기에 따라 소비되는 가스에 대한 명확한 정의가 있는 Ethereum Yellow Paper를 확인할 수 있습니다.
교환에 연결된 매개변수의 가격을 볼 수 있습니다.
각 트랜잭션에는 지불할 21000 GAS가 있습니다.
0이 아닌 각 바이트 데이터 또는 트랜잭션 코드에 대해 68 GAS를 지불합니다.
거래의 각 0바이트 데이터 또는 코드에 대해 4 GAS를 지불합니다.
따라서 Mint에 일부 NFT 속성 정보를 등록하면 트랜잭션의 데이터 부분은 abc와 같은 문자를 두 개의 16진수 표현으로 변환하고 각 문자는 8비트 바이너리로 1바이트와 동일합니다. 따라서 데이터 길이를 바이트 수로 2로 나눈 것과 거의 같을 수 있습니다.
그리고 1kb의 데이터가 정보 내용을 포함한 0이 아닌 텍스트 정보라면 68*1000=6.8W의 가스 소비를 증가시키는 것과 같습니다. 20gwei의 가스 가격과 미국 달러로 교환되는 2000 eth의 가격에 따르면 체인의 모든 1kb 데이터가 다음과 같아야 한다고 추정할 수 있습니다.
20*(21000+68000)*1e9/1e18 * 2000 = USD 3.5
func gasSStore(evm *EVM, contract *Contract, stack *Stack, mem *Memory, memorySize uint64)(uint64, error)
5.2 계약 보관 비용
트랜잭션이 시작된 후 스마트 계약에 저장된 논리가 있으므로 Ethereum go 소스 코드(EIP1283)에서 특정 소비를 분석해 보겠습니다.
역사적으로 가스 소비량의 추정은 여러 번의 반복을 거쳤으며, Petersburg 또는 Constantinople이 활성화되지 않은 경우 다음 논리에 따라 계산이 수행되지 않습니다.
가스 소모량 계산은 3가지 데이터 관리(추가, 삭제, 수정)에 따라 다름
값이 0인 주소에서 0이 아닌 값(NEW VALUE)까지 각 스토리지 슬롯은 2Wgas를 소비합니다.
0이 아닌 값 주소에서 0 값 주소(DELETE)까지 각 스토리지 슬롯은 5K 가스를 소비해야 하지만 1.5W 가스 반환의 보상이 있습니다.
0이 아닌 값에서 0이 아닌 값으로(CHANGE), 각 스토리지 슬롯은 200 가스를 소비합니다.
위의 각 스토리지 슬롯은 32바이트로 계산되며 1kb 스토리지는 32개의 스토리지 슬롯입니다. Mint의 프로세스는 새로운 스토리지를 추가하는 것이므로 추가로 1kb의 데이터가 체인에 저장되면 비용은 64Wgas가 되며 변환 금액은 다음과 같습니다.
EIP-5058은 NFT 프로젝트 당사자가 양동이를 가지고 도망가는 것을 막을 수 있습니까?
EIP-5058은 NFT 프로젝트 당사자가 양동이를 가지고 도망가는 것을 막을 수 있습니까?
