이 기사에서는 스마트 계약이 무엇인지, 스마트 계약이 무엇인지 살펴보고, 다양한 스마트 계약 플랫폼과 그 기능에 대해 알아보고, 작동 방식과 가져올 수 있는 이점에 대해 논의할 것입니다. 이 자료는 스마트 계약이라는 주제에 대해 잘 알지 못하지만 스마트 계약을 더 가까이 이해하고 싶은 독자에게 매우 유용할 것입니다.
정규계약 vs. 스마트 계약
자세한 내용을 살펴보기 전에 종이에 명시되는 일반 계약과 디지털 방식으로 표현되는 스마트 계약의 차이점을 예를 들어 보겠습니다.
스마트 계약이 등장하기 전에는 어떻게 작동했나요? 가치 분배를 위한 특정 규칙과 조건뿐만 아니라 주어진 규칙과 조건에 따라 이러한 분배의 구현을 보장하는 특정 메커니즘을 설정하려는 사람들의 그룹을 상상해 보십시오. 그런 다음 그들은 함께 모여 신원 정보, 용어, 관련 가치를 기록한 종이를 작성하고 날짜를 입력하고 서명했습니다. 이 계약은 또한 공증인과 같은 신뢰할 수 있는 당사자에 의해 인증되었습니다. 또한이 사람들은 그러한 계약서의 종이 사본을 가지고 다른 방향으로 가서 계약 자체와 일치하지 않을 수있는 몇 가지 작업을 수행하기 시작했습니다. 즉, 한 가지 일을했지만 서류상으로는 무언가를해야한다는 것이 인증되었습니다. 완전히 다릅니다. 이 상황에서 벗어나는 방법은 무엇입니까? 실제로 그룹 구성원 중 한 명이 이 문서를 가져와 몇 가지 증거를 확보하고 법원에 제출하여 계약과 실제 조치 간의 준수를 달성해야 합니다. 이 계약의 공정한 이행이 어려운 경우가 많으며, 이로 인해 불쾌한 결과가 초래됩니다.
스마트 계약에 대해 무엇을 말할 수 있나요? 이는 계약 조건 작성 가능성과 엄격한 구현 메커니즘을 결합합니다. 조건이 설정되고 해당 거래 또는 요청이 서명된 경우 해당 요청 또는 거래가 승인되면 더 이상 조건을 변경하거나 구현에 영향을 미칠 수 없습니다.
하나의 검증기 또는 전체 네트워크가 있으며 실행을 위해 제출된 모든 스마트 계약을 엄격한 시간순으로 저장하는 데이터베이스가 있습니다. 또한 이 데이터베이스에는 스마트 계약을 실행하기 위한 모든 트리거 조건이 포함되어 있어야 합니다. 또한 계약서에 분배가 설명되어 있는 바로 그 가치도 고려해야 합니다. 이것이 일부 디지털 통화에 적용된다면 이 데이터베이스는 이를 고려해야 합니다.
즉, 스마트 계약 검증자는 스마트 계약이 작동하는 모든 데이터에 액세스할 수 있어야 합니다. 예를 들어 디지털 통화, 사용자 잔액, 사용자 거래 및 타임스탬프를 동시에 설명하려면 단일 데이터베이스를 사용해야 합니다. 그러면 스마트 계약에서 조건은 사용자의 특정 통화 잔액, 특정 시간의 도래 또는 특정 거래가 수행되었다는 사실일 수 있지만 그 이상은 아닙니다.
스마트 계약의 정의
일반적으로 용어 자체는 Nick Szabo 연구원이 만들어 1994년에 처음 사용했으며, 1997년 스마트 계약의 개념을 설명하는 기사에 문서화되었습니다.
스마트 계약은 가치 분배의 일부 자동화가 수행됨을 의미하며, 이는 사전에 미리 결정된 조건에만 의존할 수 있습니다. 가장 단순한 형태로 보면 특정 당사자가 서명한 엄격하게 정의된 조건의 계약처럼 보입니다.
스마트 계약은 제XNUMX자에 대한 신뢰를 최소화하도록 설계되었습니다. 때로는 모든 것이 의존하는 의사결정 센터가 완전히 배제되는 경우도 있습니다. 또한 이러한 계약은 감사하기가 더 쉽습니다. 이는 그러한 시스템의 일부 설계 기능의 결과이지만, 대부분의 경우 스마트 계약을 통해 분산형 환경과 누구나 데이터베이스를 분석하고 계약 실행에 대한 전체 감사를 수행할 수 있는 기능의 존재를 이해합니다. 이를 통해 계약 자체의 이행 변경을 수반하는 소급 데이터 변경으로부터 보호할 수 있습니다. 스마트 계약을 생성하고 실행할 때 대부분의 프로세스를 디지털화하면 구현 기술과 비용이 단순화되는 경우가 많습니다.
간단한 예 - 에스크로 서비스
아주 간단한 예를 살펴보겠습니다. 이는 스마트 계약의 기능을 더 잘 이해하고 어떤 경우에 사용해야 하는지 더 잘 이해하는 데 도움이 될 것입니다.
비트코인을 사용해 구현할 수도 있지만, 현재로서는 비트코인을 스마트 계약을 위한 완전한 플랫폼이라고 할 수는 없습니다. 그래서 구매자가 있고 온라인 상점이 있습니다. 고객이 이 매장에서 모니터를 구매하려고 합니다. 가장 간단한 경우는 구매자가 결제를 완료하고 보내면 온라인 상점에서 이를 수락하고 확인한 후 상품을 배송하는 것입니다. 그러나 이 상황에서는 큰 신뢰가 필요합니다. 구매자는 모니터의 전체 비용에 대해 온라인 상점을 신뢰해야 합니다. 온라인 상점은 구매자의 눈에 낮은 평판을 가질 수 있으므로 어떤 이유로 결제를 수락한 후 상점에서 서비스를 거부하고 구매자에게 상품을 보내지 않을 위험이 있습니다. 따라서 구매자는 이러한 위험을 최소화하고 거래의 신뢰성을 높이기 위해 이 경우 무엇을 적용할 수 있는지 질문합니다(따라서 온라인 상점에서도 이 질문을 합니다).
비트코인의 경우 구매자와 판매자가 독립적으로 중재자를 선택할 수 있도록 하는 것이 가능합니다. 논란이 되는 문제를 해결하는 데 참여하는 사람들이 많이 있습니다. 그리고 참가자들은 일반 중재자 목록에서 신뢰할 수 있는 중재자를 선택할 수 있습니다. 그들은 함께 2개의 키가 있는 3개의 다중 서명 주소 중 XNUMX개를 생성하고 해당 주소에서 코인을 사용하려면 두 개의 키가 있는 두 개의 서명이 필요합니다. 하나의 키는 구매자에게 속하고, 두 번째는 온라인 상점에, 세 번째는 중재자에게 속합니다. 그리고 구매자는 다중 서명 주소로 모니터 비용을 지불하는 데 필요한 금액을 보냅니다. 이제 판매자가 자신에게 의존하는 다중 서명 주소에서 돈이 한동안 차단된 것을 확인하면 안전하게 모니터를 우편으로 보낼 수 있습니다.
다음으로 구매자는 소포를 받고 상품을 검사한 후 최종 구매 결정을 내립니다. 그는 제공된 서비스에 완전히 동의하고 자신의 키로 거래에 서명하여 다중 서명 주소에서 판매자에게 코인을 전송하거나 무언가에 만족하지 않을 수 있습니다. 두 번째 경우, 그는 중재자에게 연락하여 해당 코인을 다르게 분배할 대체 거래를 구성합니다.
모니터가 약간 긁힌 채 도착했고 키트에 컴퓨터 연결용 케이블이 포함되어 있지 않다고 가정해 보겠습니다. 하지만 온라인 상점 웹사이트에는 케이블이 키트에 포함되어야 한다고 나와 있습니다. 그런 다음 구매자는 이 상황에서 자신이 속았다는 것을 중재자에게 증명하는 데 필요한 증거를 수집합니다. 그는 사이트의 스크린샷을 찍고, 우편 영수증 사진을 찍고, 모니터의 흠집 사진을 찍어 봉인이 부러져서 케이블이 뽑혔습니다. 그러면 온라인 상점은 증거를 수집하여 중재자에게 전달합니다.
중재자는 구매자의 분노와 온라인 상점의 이익을 동시에 만족시키는 데 관심이 있습니다(이유는 나중에 밝혀집니다). 이는 다중 서명 주소의 코인이 구매자, 온라인 상점 및 중재자 사이에서 일정 비율로 소비되는 거래를 구성합니다. 왜냐하면 구매자는 자신의 작업에 대한 보상으로 일부를 가져가기 때문입니다. 총액의 90%는 판매자에게, 5%는 중재자에게, 5%는 구매자에게 보상으로 전달된다고 가정해 보겠습니다. 중재자는 자신의 키로 이 거래에 서명하지만 두 개의 서명이 필요하지만 하나만 가치가 있기 때문에 아직 적용할 수 없습니다. 이는 구매자와 판매자 모두에게 그러한 거래를 보냅니다. 그들 중 적어도 하나가 코인 재배포 옵션에 만족한다면 거래는 사전 서명되어 네트워크에 배포됩니다. 이를 검증하려면 거래 당사자 중 하나가 중재자의 선택에 동의하는 것으로 충분합니다.
두 참가자가 모두 신뢰할 수 있도록 처음에 중재자를 선택하는 것이 중요합니다. 이 경우 그는 서로의 이익과 독립적으로 행동하고 상황을 객관적으로 평가합니다. 중재자가 최소 한 명의 참가자를 만족시킬 수 있는 코인 배포 옵션을 제공하지 않는 경우, 함께 동의한 후 구매자와 온라인 상점은 두 개의 서명을 입력하여 새로운 다중 서명 주소로 코인을 보낼 수 있습니다. 새로운 다중 서명 주소는 해당 문제에 대해 더 유능하고 더 나은 옵션을 제공할 수 있는 다른 중재자와 함께 작성됩니다.
기숙사와 냉장고의 예
스마트 계약의 기능을 보다 명시적으로 표시하는 보다 복잡한 예를 살펴보겠습니다.
최근 같은 기숙사로 이사한 세 남자가 있다고 가정해 보겠습니다. 세 사람은 함께 사용할 수 있는 방용 냉장고를 구입하는 데 관심이 있습니다. 그들 중 한 명은 냉장고 구입에 필요한 금액을 모으고 판매자와 협상을 하기 위해 자원했습니다. 하지만 두 사람은 만난 지 얼마 되지 않아 신뢰가 부족한 상황이다. 분명히 그 중 두 사람은 세 번째 사람에게 돈을 줌으로써 위험을 감수하고 있습니다. 또한 판매자 선택에 있어서도 합의가 필요합니다.
그들은 에스크로 서비스를 사용할 수 있습니다. 즉, 거래 실행을 모니터링하고 논란이 되는 문제가 발생할 경우 이를 해결할 중재자를 선택할 수 있습니다. 그런 다음 동의한 후 스마트 계약을 작성하고 그 안에 특정 조건을 규정합니다.
첫 번째 조건은 특정 시간 이전, 예를 들어 일주일 이내에 해당 스마트 계약 계정이 특정 주소로부터 특정 금액에 대해 세 번의 지불을 받아야 한다는 것입니다. 이것이 발생하지 않으면 스마트 계약은 실행을 중단하고 모든 참가자에게 코인을 반환합니다. 조건이 충족되면 판매자 및 중개자 식별자의 값이 설정되고 모든 참가자가 판매자 및 중개자의 선택에 동의하는지 조건이 확인됩니다. 모든 조건이 충족되면 자금이 지정된 주소로 이체됩니다. 이 접근 방식은 모든 측면에서 사기로부터 참가자를 보호할 수 있으며 일반적으로 신뢰의 필요성을 제거합니다.
우리는 이 예에서 각 조건을 충족하기 위한 매개변수를 단계별로 설정하는 기능을 통해 중첩된 수준의 복잡성과 깊이가 있는 시스템을 만들 수 있다는 원리를 볼 수 있습니다. 또한 먼저 스마트 계약의 첫 번째 조건을 정의할 수 있으며, 해당 조건이 이행된 후에만 다음 조건에 대한 매개변수를 설정할 수 있습니다. 즉, 조건이 공식적으로 작성되어 있으며 해당 조건에 대한 매개변수는 해당 작업 중에 이미 설정될 수 있습니다.
스마트 계약의 분류
분류를 위해 다양한 기준 그룹을 설정할 수 있습니다. 그러나 기술이 발전하는 시점에서는 그 중 XNUMX개가 관련이 있다.
스마트 계약은 중앙 집중식 또는 분산형 실행 환경으로 구별될 수 있습니다. 분산화의 경우 스마트 계약을 실행할 때 훨씬 더 큰 독립성과 내결함성을 갖습니다.
또한 조건을 설정하고 충족하는 과정으로 구별할 수 있습니다. 즉, 자유롭게 프로그래밍할 수 있고, 제한하거나 사전 정의할 수 있습니다. 즉, 엄격하게 입력할 수 있습니다. 스마트 계약 플랫폼에 특정 스마트 계약이 4개만 있는 경우 해당 매개변수는 어떤 방식으로든 설정할 수 있습니다. 따라서 설정이 훨씬 간단합니다. 목록에서 계약을 선택하고 매개변수를 전달합니다.
개시 방식에 따르면 자동화된 스마트 계약, 즉 특정 조건이 발생하면 자체 실행되는 계약이 있고, 조건이 지정되어 있지만 플랫폼이 자동으로 이행 여부를 확인하지 않는 계약이 있습니다. 별도로 시작해야 합니다.
또한 스마트 계약은 개인정보 보호 수준에 따라 다릅니다. 완전히 공개되거나, 부분적으로 또는 완전히 기밀로 유지될 수 있습니다. 후자는 제XNUMX자 관찰자가 스마트 계약 조건을 볼 수 없음을 의미합니다. 그러나 개인 정보 보호라는 주제는 매우 광범위하므로 현재 기사와 별도로 고려하는 것이 좋습니다.
아래에서는 현재 주제를 더 명확하게 이해하기 위해 처음 세 가지 기준을 자세히 살펴보겠습니다.
런타임별 스마트 계약
실행 환경에 따라 중앙 집중식 스마트 계약 플랫폼과 분산형 스마트 계약 플랫폼이 구분됩니다. 중앙 집중식 디지털 계약의 경우 단일 서비스가 사용되며, 검증인은 단 한 명뿐이고 중앙에서 관리되는 백업 및 복구 서비스도 있을 수 있습니다. 스마트 계약 조건을 설정하고 바로 이 서비스 데이터베이스에서 고려되는 가치를 분배하는 데 필요한 모든 정보를 저장하는 하나의 데이터베이스가 있습니다. 이러한 중앙 집중식 서비스에는 특정 요청에 대해 조건을 설정하고 해당 계약을 사용하는 클라이언트가 있습니다. 플랫폼의 중앙집중적 특성으로 인해 인증 메커니즘은 암호화폐보다 덜 안전할 수 있습니다.
예를 들어 이동통신사(다양한 이동통신사)를 들 수 있습니다. 특정 운영자가 서버에 트래픽에 대한 중앙 집중식 기록을 보관한다고 가정해 보겠습니다. 이 기록은 음성 통화, SMS 전송, 모바일 인터넷 트래픽 등 다양한 형식으로 전송될 수 있으며 다양한 표준에 따라 기록도 유지됩니다. 사용자 잔액에 대한 자금. 이에 따라 이동통신사업자는 제공되는 서비스에 대한 정산 및 결제에 관한 계약을 다양한 조건으로 체결할 수 있습니다. 이 경우 "이러한 번호로 이러저러한 코드가 포함된 SMS를 보내면 트래픽 분산을 위한 이러저러한 조건을 받게 됩니다."와 같은 조건을 설정하기 쉽습니다.
또 하나의 예를 들 수 있습니다. 인터넷 뱅킹의 확장된 기능과 정기 결제, 입금 자동 전환, 특정 계좌에 대한 이자 자동 공제 등과 같은 매우 간단한 계약을 갖춘 기존 은행입니다.
분산된 실행 환경을 갖춘 스마트 계약에 관해 이야기하고 있다면 검증자 그룹이 있습니다. 이상적으로는 누구나 검증인이 될 수 있습니다. 데이터베이스 동기화 프로토콜 및 합의 도달로 인해 이제 형식이 자주 변경되는 일부 조건부 쿼리가 아닌 엄격하게 설명된 계약을 사용하여 모든 트랜잭션을 저장하는 공통 데이터베이스가 있으며 공개 사양이 없습니다. 여기서 트랜잭션에는 엄격한 사양에 따라 계약을 실행하기 위한 지침이 포함됩니다. 이 사양은 공개되어 있으므로 플랫폼 사용자가 직접 스마트 계약을 감사하고 검증할 수 있습니다. 여기서 우리는 분산형 플랫폼이 독립성과 내결함성 측면에서 중앙형 플랫폼보다 우수하지만 설계 및 유지 관리가 훨씬 더 복잡하다는 것을 알 수 있습니다.
조건 설정 및 이행 방식에 따른 스마트 계약
이제 스마트 계약이 조건을 설정하고 이행하는 방식이 어떻게 다른지 자세히 살펴보겠습니다. 여기서 우리는 무작위로 프로그래밍 가능하고 튜링 완성형 스마트 계약에 관심을 돌립니다. Turing-complete 스마트 계약을 사용하면 쓰기 주기, 확률 계산을 위한 일부 기능 등 거의 모든 알고리즘을 계약 실행 조건으로 설정할 수 있으며 자체 전자 서명 알고리즘까지 가능합니다. 이 경우 우리는 정말로 임의적인 논리 작성을 의미합니다.
임의의 스마트 계약도 있지만 Turing 완전한 계약은 없습니다. 여기에는 자체 스크립트가 있는 비트코인과 라이트코인이 포함됩니다. 즉, 순서에 관계없이 특정 작업만 사용할 수 있지만 더 이상 루프와 자체 알고리즘을 작성할 수는 없습니다.
또한 사전 정의된 스마트 계약을 구현하는 스마트 계약 플랫폼도 있습니다. 여기에는 Bitshares와 Steemit이 포함됩니다. Bitshares는 거래, 계정 관리, 플랫폼 자체 및 해당 매개변수 관리를 위한 다양한 스마트 계약을 보유하고 있습니다. Steemit은 유사한 플랫폼이지만 더 이상 Bitshares처럼 토큰 발행 및 거래에 중점을 두지 않고 블로그에 집중합니다. 즉, 분산된 방식으로 콘텐츠를 저장하고 처리합니다.
임의의 튜링 완료 계약에는 아직 개발 중인 Ethereum 플랫폼과 RootStock이 포함됩니다. 따라서 아래에서는 Ethereum 스마트 계약 플랫폼에 대해 좀 더 자세히 설명하겠습니다.
개시 방법별 스마트 계약
개시 방법에 따라 스마트 계약은 자동화 및 수동(자동화 아님)의 두 가지 그룹으로 나눌 수도 있습니다. 자동화된 계약은 알려진 모든 매개변수와 조건이 주어지면 스마트 계약이 완전히 자동으로 실행된다는 사실이 특징입니다. 즉, 추가 거래를 보내고 각 후속 실행에 추가 수수료를 지출할 필요가 없습니다. 플랫폼 자체에는 스마트 계약이 어떻게 완료될지 계산하는 데 필요한 모든 데이터가 있습니다. 거기의 논리는 임의적이지 않고 미리 결정되어 있으며 이 모든 것이 예측 가능합니다. 즉, 스마트 계약 실행의 복잡성을 미리 예측하고 이를 위해 일정한 수수료를 사용할 수 있으며 구현을 위한 모든 프로세스가 더 효율적입니다.
자유롭게 프로그래밍된 스마트 계약의 경우 실행이 자동화되지 않습니다. 이러한 스마트 계약을 시작하려면 거의 모든 단계에서 다음 실행 단계 또는 다음 스마트 계약 방법을 호출하는 새 거래를 생성하고 적절한 수수료를 지불하고 거래가 확인될 때까지 기다려야 합니다. 스마트 계약 코드가 임의적이고 영원한 루프, 일부 매개변수 및 인수 부족, 처리되지 않은 예외 등과 같은 예측할 수 없는 순간이 나타날 수 있기 때문에 실행이 성공적으로 완료되거나 완료되지 않을 수 있습니다.
이더리움 계정
이더리움 계정 유형
Ethereum 플랫폼에 어떤 유형의 계정이 있을 수 있는지 살펴보겠습니다. 여기에는 두 가지 유형의 계정만 있으며 다른 옵션은 없습니다. 첫 번째 유형을 사용자 계정이라고 하고 두 번째 유형을 계약 계정이라고 합니다. 그들이 어떻게 다른지 알아 봅시다.
사용자 계정은 전자 서명의 개인 키에 의해서만 제어됩니다. 계정 소유자는 ECDSA(타원 곡선 디지털 서명 알고리즘) 알고리즘을 사용하여 전자 서명을 위한 자신의 키 쌍을 생성합니다. 이 키로 서명된 거래만 이 계정의 상태를 변경할 수 있습니다.
스마트 컨트랙트 계정에는 별도의 로직이 제공됩니다. 이는 스마트 계약의 동작을 완전히 결정하는 사전 정의된 소프트웨어 코드에 의해서만 제어될 수 있습니다. 즉, 특정 상황에서 코인을 관리하는 방법, 사용자의 주도권 및 이러한 코인이 배포될 추가 조건에서 제어할 수 있습니다. 프로그램 코드에서 개발자가 일부 사항을 제공하지 않으면 문제가 발생할 수 있습니다. 예를 들어, 스마트 계약은 사용자로부터 추가 실행 개시를 허용하지 않는 특정 상태를 수신할 수 있습니다. 이 경우 스마트 계약이 이 상태를 종료하는 기능을 제공하지 않기 때문에 코인은 실제로 동결됩니다.
이더리움에서 계정이 생성되는 방법
사용자 계정의 경우 소유자는 ECDSA를 사용하여 독립적으로 키 쌍을 생성합니다. Ethereum은 전자 서명에 대해 Bitcoin과 정확히 동일한 알고리즘과 동일한 타원 곡선을 사용하지만 주소는 약간 다른 방식으로 계산된다는 점에 유의하는 것이 중요합니다. 여기서는 비트코인처럼 이중 해싱의 결과를 더 이상 사용하지 않고, 단일 해싱을 256비트 길이의 케착(Keccak) 함수로 제공한다. 결과 값에서 최하위 비트, 즉 출력 해시 값의 최하위 160비트가 잘립니다. 결과적으로 우리는 Ethereum에서 주소를 얻습니다. 실제로는 20바이트를 차지합니다.
주소가 체크섬을 추가하여 기본 58 숫자 시스템으로 인코딩되는 비트코인 및 기타 많은 시스템과 달리 이더리움의 계정 식별자는 체크섬을 적용하지 않고 XNUMX진수로 인코딩됩니다. 이는 이더리움에서 계정 식별자로 작업할 때 주의해야 함을 의미합니다. 식별자에 단 한 번의 실수라도 코인 손실로 이어질 수 있다는 것이 보장됩니다.
중요한 기능이 있는데, 첫 번째 입금을 수락하는 순간 일반 데이터베이스 수준의 사용자 계정이 생성된다는 것입니다.
스마트 계약 계정을 생성하는 방법은 완전히 다른 접근 방식을 취합니다. 처음에 사용자 중 한 명이 스마트 계약의 소스 코드를 작성한 후 코드가 Ethereum 플랫폼용 특수 컴파일러를 통해 전달되어 자체 Ethereum 가상 머신에 대한 바이트코드를 얻습니다. 결과 바이트코드는 트랜잭션의 특수 필드에 배치됩니다. 개시자의 계정을 대신하여 인증됩니다. 다음으로, 이 거래는 네트워크 전체에 전파되어 스마트 계약 코드를 배치합니다. 거래 수수료 및 그에 따른 계약 실행 수수료는 개시자의 계정 잔액에서 인출됩니다.
각 스마트 계약에는 반드시 (본 계약의) 자체 생성자가 포함됩니다. 비어 있을 수도 있고 내용이 있을 수도 있습니다. 생성자가 실행된 후 스마트 계약 계정 식별자가 생성되며 이를 사용하여 코인을 보내고 특정 스마트 계약 메서드를 호출하는 등의 작업을 수행할 수 있습니다.
이더리움 거래 구조
더 명확하게 하기 위해 이더리움 트랜잭션의 구조와 스마트 계약 코드 예시를 살펴보겠습니다.
Ethereum 트랜잭션은 여러 필드로 구성됩니다. 첫 번째 nonce는 거래를 배포하고 작성자인 계정 자체와 관련된 거래의 특정 일련 번호입니다. 이는 이중 거래를 구별하기 위해, 즉 동일한 거래가 두 번 승인되는 경우를 배제하기 위해 필요합니다. 식별자를 사용하면 각 거래마다 고유한 해시 값이 있습니다.
다음은 다음과 같은 필드입니다. 가스 가격. 이는 이더리움 기본 통화가 가스로 변환되는 가격을 나타내며, 이는 스마트 계약 실행 및 가상 머신 리소스 할당 비용을 지불하는 데 사용됩니다. 무슨 뜻이에요?
비트코인에서는 수수료가 기본 통화인 비트코인 자체를 통해 직접 지불됩니다. 이는 간단한 계산 메커니즘 덕분에 가능합니다. 우리는 거래에 포함된 데이터의 양에 대해 엄격하게 비용을 지불합니다. 이더리움에서는 거래 데이터의 양에 의존하기가 매우 어렵기 때문에 상황이 더 복잡합니다. 여기서, 트랜잭션에는 가상 머신에서 실행될 프로그램 코드도 포함될 수 있으며, 가상 머신의 각 동작은 서로 다른 복잡도를 가질 수 있다. 변수에 메모리를 할당하는 작업도 있습니다. 각 작업에 대한 지불이 달라지는 자체 복잡성이 있습니다.
가스 환산의 각 작업 비용은 일정합니다. 각 작업의 일정한 비용을 결정하기 위해 특별히 도입되었습니다. 네트워크의 부하에 따라 가스 가격이 변경됩니다. 즉, 수수료를 지불하기 위해 기본 통화가 이 보조 단위로 변환되는 계수가 변경됩니다.
이더리움 트랜잭션에는 한 가지 기능이 더 있습니다. 가상 머신에서 실행하기 위해 포함된 바이트코드는 어떤 결과(성공 또는 실패)로 완료될 때까지 또는 커미션을 지불하기 위해 할당된 특정 양의 코인이 소진될 때까지 실행됩니다. . 오류가 발생하는 경우 보낸 사람 계정의 모든 코인이 수수료에 소비되는 상황(예: 가상 머신에서 시작된 일종의 영구 주기)을 피하기 위해 다음 필드가 존재합니다. 가스를 시작하다 (종종 가스 한도라고도 함) - 보낸 사람이 특정 거래를 완료하기 위해 기꺼이 소비할 코인의 최대 금액을 결정합니다.
다음 필드가 호출됩니다. 목적지 주소. 여기에는 코인 수령인의 주소 또는 메소드가 호출될 특정 스마트 계약의 주소가 포함됩니다. 그 후에는 필드가 나옵니다. 가치, 목적지 주소로 전송된 코인의 양을 입력하는 곳입니다.
다음은 다음과 같은 흥미로운 필드입니다. 데이터, 전체 구조가 맞는 곳. 이는 별도의 필드가 아니고, 가상 머신에 대한 코드가 정의되어 있는 전체 구조입니다. 여기에 임의의 데이터를 배치할 수 있습니다. 이에 대한 별도의 규칙이 있습니다.
그리고 마지막 필드는 서명. 여기에는 이 거래 작성자의 전자 서명과 이 서명이 확인되는 공개 키가 동시에 포함됩니다. 공개 키를 통해 이 거래를 보낸 사람의 계정 식별자를 얻을 수 있습니다. 즉, 시스템 자체에서 보낸 사람의 계정을 고유하게 식별할 수 있습니다. 우리는 거래 구조에 대한 주요 사항을 알아냈습니다.
Solidity용 스마트 계약 코드 예시
이제 예를 사용하여 가장 간단한 스마트 계약을 자세히 살펴보겠습니다.
contract Bank {
address owner;
mapping(address => uint) balances;
function Bank() {
owner = msg.sender;
}
function deposit() public payable {
balances[msg.sender] += msg.value;
}
function withdraw(uint amount) public {
if (balances[msg.sender] >= amount) {
balances[msg.sender] -= amount;
msg.sender.transfer(amount);
}
}
function getMyBalance() public view returns(uint) {
return balances[msg.sender];
}
function kill() public {
if (msg.sender == owner)
selfdestruct(owner);
}
}위는 사용자의 코인을 보유하고 요청 시 반환할 수 있는 단순화된 소스 코드입니다.
따라서 다음과 같은 기능을 수행하는 은행 스마트 계약이 있습니다. 잔액에 코인을 축적합니다. 즉, 거래가 확인되고 스마트 계약이 체결되면 잔액에 코인을 담을 수 있는 새 계정이 생성됩니다. 사용자와 그들 사이의 코인 분배를 기억합니다. 잔액을 관리하는 방법에는 여러 가지가 있습니다. 즉, 사용자의 잔액을 보충하고 인출하고 확인할 수 있습니다.
소스 코드의 각 줄을 살펴보겠습니다. 이 계약에는 상수 필드가 있습니다. 그 중 하나는 주소 유형을 가지며 소유자라고 합니다. 여기서 계약은 이 스마트 계약을 생성한 사용자의 주소를 기억합니다. 또한 사용자 주소와 잔액 간의 대응을 유지하는 동적 구조가 있습니다.
그 다음에는 Bank 메소드가 옵니다. 이는 계약과 동일한 이름을 갖습니다. 따라서 이것이 생성자입니다. 여기서 소유자 변수에는 이 스마트 계약을 네트워크에 배치한 사람의 주소가 할당됩니다. 이것이 이 생성자에서 일어나는 유일한 일입니다. 즉, 이 경우의 msg는 바로 이 컨트랙트의 전체 코드가 포함된 트랜잭션과 함께 가상 머신으로 전송된 데이터입니다. 따라서 msg.sender는 이 코드를 호스팅하는 이 트랜잭션의 작성자입니다. 그는 스마트 계약의 소유자가 될 것입니다.
입금 방식을 사용하면 거래를 통해 일정 수량의 코인을 계약 계좌로 이체할 수 있습니다. 이 경우, 이러한 코인을 받은 스마트 계약은 이를 대차대조표에 남겨 두지만, 해당 코인이 누구에게 속해 있는지 알기 위해 정확히 이 코인의 보낸 사람이 누구인지 잔액 구조에 기록합니다.
다음 메소드는 인출(withdrawal)이라고 하며 하나의 매개변수, 즉 누군가가 이 은행에서 인출하려는 코인의 양을 사용합니다. 이 메서드를 호출하여 코인을 보내는 사용자의 잔액에 코인이 충분한지 확인합니다. 코인이 충분하다면 스마트 계약 자체가 해당 코인 수를 호출자에게 반환합니다.
다음은 사용자의 현재 잔액을 확인하는 방법입니다. 이 메소드를 호출하는 사람은 스마트 계약에서 이 잔액을 검색하는 데 사용됩니다. 이 메소드의 수정자가 view라는 점은 주목할 가치가 있습니다. 즉, 메서드 자체는 클래스의 변수를 어떤 식으로든 변경하지 않으며 실제로는 읽기 메서드일 뿐입니다. 이 메서드를 호출하기 위해 별도의 트랜잭션이 생성되지 않고 수수료도 지불되지 않으며 모든 계산이 로컬에서 수행된 후 사용자가 결과를 받습니다.
스마트 계약의 상태를 파괴하려면 kill 메소드가 필요합니다. 그리고 이 메서드의 호출자가 이 계약의 소유자인지 여부를 추가로 확인합니다. 그렇다면 계약은 자동 소멸되고 파괴 기능은 하나의 매개변수, 즉 계약이 잔액에 남아 있는 모든 코인을 보낼 계정 식별자를 사용합니다. 이 경우 남은 코인은 자동으로 계약 소유자의 주소로 이동됩니다.
Ethereum 네트워크의 전체 노드는 어떻게 작동합니까?
이러한 스마트 계약이 이더리움 플랫폼에서 어떻게 실행되는지, 전체 네트워크 노드가 어떻게 작동하는지 개략적으로 살펴보겠습니다.
Ethereum 네트워크의 전체 노드에는 최소 XNUMX개의 모듈이 있어야 합니다.
첫 번째는 분산형 프로토콜과 마찬가지로 P2P 네트워킹 모듈입니다. 이는 네트워크 연결을 위한 모듈이며 다른 노드에 대한 블록, 트랜잭션 및 정보가 교환되는 다른 노드와 작동합니다. 이는 모든 분산형 암호화폐의 전통적인 구성 요소입니다.
다음으로, 블록체인 데이터 저장, 처리, 우선순위 분기 선택, 블록 추가, 블록 연결 해제, 해당 블록 검증 등을 위한 모듈이 있습니다.
세 번째 모듈은 EVM(Ethereum Virtual Machine)이라고 하며, Ethereum 트랜잭션에서 바이트코드를 수신하는 가상 머신입니다. 이 모듈은 특정 계정의 현재 상태를 가져와 수신된 바이트코드를 기반으로 상태를 변경합니다. 각 네트워크 노드의 가상 머신 버전은 동일해야 합니다. 각 이더리움 노드에서 발생하는 계산은 정확히 동일하지만 비동기식으로 발생합니다. 누군가가 이 트랜잭션을 더 일찍 확인하고 수락합니다. 즉, 여기에 포함된 모든 코드를 실행하고 누군가는 나중에 실행합니다. 따라서 트랜잭션이 생성되면 네트워크에 분산되어 노드들이 이를 수락하고, 검증 시에는 비트코인에서 비트코인 스크립트가 실행되는 것과 마찬가지로 여기서 가상머신의 바이트코드가 실행된다.
거래에 포함된 모든 코드가 실행되고, 특정 계정의 새로운 상태가 생성되어 이 거래가 적용되었는지 여부가 명확해질 때까지 저장되면 거래가 검증된 것으로 간주됩니다. 트랜잭션이 적용되면 이 상태는 완료되었을 뿐만 아니라 현재 상태로도 간주됩니다. 각 네트워크 노드에 대한 각 계정의 상태를 저장하는 데이터베이스가 있습니다. 모든 계산이 동일한 방식으로 발생하고 블록체인의 상태가 동일하기 때문에 모든 계정의 상태를 포함하는 데이터베이스도 각 노드에 대해 동일합니다.
스마트 계약의 신화와 한계
Ethereum과 유사한 스마트 계약 플랫폼에 존재하는 제한 사항은 다음과 같습니다.
- 코드 실행;
- 메모리 할당;
- 블록체인 데이터;
- 지불금을 보내십시오;
- 새로운 계약을 작성하십시오.
- 다른 계약을 호출합니다.
가상 머신에 적용되는 제한 사항을 살펴보고 그에 따라 스마트 계약에 대한 몇 가지 오해를 풀어보겠습니다. Ethereum뿐만 아니라 유사한 플랫폼에도 있을 수 있는 가상 머신에서는 임의의 논리적 작업, 즉 코드를 작성하면 실행될 수 있으며 추가로 메모리를 할당할 수 있습니다. 그러나 각 작업 및 할당된 추가 메모리 단위에 대해 요금이 별도로 지불됩니다.
다음으로, 가상 머신은 블록체인 데이터베이스에서 데이터를 읽어 이 데이터를 하나 또는 다른 스마트 계약 논리를 실행하는 트리거로 사용할 수 있습니다. 가상 머신은 트랜잭션을 생성하고 보낼 수 있으며, 새로운 계약을 생성하고 이미 네트워크에 게시된 다른 스마트 계약의 방법(기존, 사용 가능 등)을 호출할 수 있습니다.
가장 흔한 신화는 Ethereum 스마트 계약이 모든 인터넷 리소스의 정보를 해당 용어로 사용할 수 있다는 것입니다. 진실은 가상 머신이 인터넷의 일부 외부 정보 리소스에 네트워크 요청을 보낼 수 없다는 것입니다. 즉, 외부 날씨에 따라 사용자 간에 가치를 분배하는 스마트 계약을 작성하는 것은 불가능합니다. 또는 누가 챔피언십에서 우승했는지, 또는 외부 세계에서 발생한 다른 사건을 기반으로 합니다. 왜냐하면 이러한 사건에 대한 정보는 단순히 플랫폼 자체의 데이터베이스에 없기 때문입니다. 즉, 블록체인에는 이에 대한 내용이 없습니다. 여기에 나타나지 않으면 가상 머신은 이 데이터를 트리거로 사용할 수 없습니다.
이더리움의 단점
주요 내용을 나열해 보겠습니다. 첫 번째 단점은 Ethereum에서 스마트 계약을 설계, 개발 및 테스트하는 데 몇 가지 어려움이 있다는 것입니다(Ethereum은 Solidity 언어를 사용하여 스마트 계약을 작성합니다). 실제로 실습에 따르면 모든 오류의 매우 큰 비율이 인적 요소에 속합니다. 이는 실제로 평균 이상의 복잡성을 지닌 이미 작성된 Ethereum 스마트 계약에 해당됩니다. 단순한 스마트 계약의 경우 오류 가능성이 적다면, 복잡한 스마트 계약에서는 자금 도난, 동결, 예상치 못한 방식의 스마트 계약 파기 등으로 이어지는 오류가 매우 자주 발생합니다. 이러한 사례는 이미 많이 발생했습니다. 모두 다 아는.
두 번째 단점은 가상 머신 자체도 사람이 작성하기 때문에 완벽하지 않다는 것입니다. 이는 임의의 명령을 실행할 수 있으며 그 안에 취약점이 있습니다. 다수의 명령이 사전에 예측하지 못한 결과를 초래할 수 있는 특정 방식으로 구성될 수 있습니다. 이는 매우 복잡한 영역이지만 이러한 취약점이 현재 버전의 이더리움 네트워크에 존재하며 많은 스마트 계약의 실패로 이어질 수 있음을 보여주는 여러 연구가 이미 있습니다.
또 다른 큰 어려움은 단점이라고 할 수 있습니다. 가상 머신에서 실행될 계약의 바이트 코드를 컴파일하면 특정 작업 순서를 결정할 수 있다는 결론에 실질적으로 또는 기술적으로 도달할 수 있다는 사실에 있습니다. 이러한 작업을 함께 수행하면 가상 머신에 큰 부하가 걸리고 해당 작업을 수행하기 위해 지불한 요금에 비해 속도가 지나치게 느려집니다.
과거에는 이미 이더리움 개발 기간이 있었고, 가상 머신의 작동을 자세히 이해한 많은 사람들이 이러한 취약점을 발견했습니다. 실제로 거래는 매우 적은 수수료를 지불했지만 실제로 전체 네트워크 속도를 저하시켰습니다. 이러한 문제는 해결하기가 매우 어렵습니다. 첫째, 문제를 결정하고, 둘째, 이러한 작업을 수행하기 위한 가격을 조정하고, 셋째, 모든 네트워크 노드를 새 버전으로 업데이트하는 하드포크를 수행해야 하기 때문입니다. 소프트웨어를 설치한 다음 이러한 변경 사항을 동시에 활성화합니다.
이더리움에 관해서는 많은 연구가 수행되었고 많은 실제 경험이 얻어졌습니다. 긍정적이든 부정적이든 그럼에도 불구하고 여전히 어떻게든 해결해야 할 어려움과 취약점이 남아 있습니다.
이제 기사의 주제 부분이 완성되었습니다. 자주 발생하는 질문으로 넘어가겠습니다.
FAQ
— 기존 스마트 계약의 모든 당사자가 조건을 변경하려는 경우 다중 서명을 사용하여 이 스마트 계약을 취소한 다음 업데이트된 실행 조건으로 새 스마트 계약을 생성할 수 있습니까?
여기에 대한 대답은 두 가지가 될 것입니다. 왜? 왜냐하면 스마트 계약은 한 번 정의되면 더 이상 변경 사항을 의미하지 않는 반면, 일부 조건의 전체 또는 부분 변경을 제공하는 사전 작성된 논리를 가질 수 있기 때문입니다. 즉, 스마트 계약의 내용을 변경하려면 이러한 조건을 업데이트할 수 있는 조건을 규정해야 합니다. 따라서 그러한 신중한 방식으로만 계약 갱신을 조직할 수 있습니다. 그러나 여기서도 문제에 봉착할 수 있습니다. 실수를 하면 이에 상응하는 취약점이 발생합니다. 따라서 이러한 사항은 매우 상세하고 신중하게 설계 및 테스트되어야 합니다.
— 중재자가 참여 당사자 중 하나(에스크로 또는 스마트 계약)와 계약을 체결하면 어떻게 되나요? 스마트 계약에 중재자가 필요합니까?
스마트 계약에는 중재자가 필요하지 않습니다. 존재하지 않을 수도 있습니다. 에스크로의 경우 중재자가 당사자 중 한 명과 음모를 꾸미는 경우, 그렇습니다. 그러면 이 계획은 그 가치를 급격히 잃습니다. 따라서 중재자는 이 과정에 관련된 모든 당사자가 동시에 신뢰하는 방식으로 선택됩니다. 따라서 귀하는 신뢰하지 않는 중재자를 통해 다중 서명 주소로 코인을 전송하지 않을 것입니다.
— 하나의 이더리움 거래를 통해 귀하의 주소에서 다양한 대상 주소(예: 이러한 토큰이 거래되는 거래소 주소)로 다양한 토큰을 전송할 수 있습니까?
이것은 좋은 질문이며 이더리움 거래 모델과 비트코인 모델과의 차이점에 관한 것입니다. 그리고 그 차이는 근본적입니다. Ethereum 거래 모델에서 단순히 코인을 전송하는 경우 한 주소에서 다른 주소로만 전송되며 변경 사항은 없으며 지정한 특정 금액만 전송됩니다. 즉, 이는 미사용 출력(UTXO) 모델이 아니라 계정 및 해당 잔액 모델입니다. 교활한 스마트 계약을 작성하면 이론적으로 한 거래에서 여러 개의 다른 토큰을 한 번에 보내는 것이 가능하지만 여전히 많은 거래를 하고 계약을 만든 다음 여기에 토큰과 코인을 전송하고 적절한 메서드를 호출해야 합니다. . 이를 위해서는 노력과 시간이 필요하므로 실제로는 그렇게 작동하지 않으며 이더리움의 모든 지불은 별도의 거래로 이루어집니다.
— 이더리움 플랫폼에 대한 신화 중 하나는 외부 인터넷 리소스의 데이터에 의존하는 조건을 설명하는 것이 불가능하다는 것입니다. 그렇다면 어떻게 해야 할까요?
해결책은 스마트 계약 자체가 외부 세계의 상태에 대한 데이터를 수집하고 특별한 방법을 통해 스마트 계약에 전송하는 소위 신뢰할 수 있는 오라클을 하나 이상 제공할 수 있다는 것입니다. 계약 자체는 신뢰할 수 있는 당사자로부터 받은 데이터를 사실로 간주합니다. 신뢰성을 높이려면 대규모 오라클 그룹을 선택하고 공모 위험을 최소화하세요. 계약 자체는 대다수와 모순되는 오라클의 데이터를 고려하지 않을 수 있습니다.
블록체인 온라인 강좌의 강의 중 하나가 이 주제를 다룹니다.".
출처 : habr.com