기술적 분석: 이더리움, 비트코인 ​​및 비트코인 ​​캐시의 스마트 계약의 차이점은 무엇입니까?

편집자 주: 이 기사의 출처는퍼스트 클래스 창고(ID: first_vip1), 승인을 받아 Odaily에서 재인쇄했습니다.

편집자 주: 이 기사의 출처는

퍼스트 클래스 창고(ID: first_vip1)

, 승인을 받아 Odaily에서 재인쇄했습니다.

이 기사는 이 세 가지 플랫폼에서 스마트 계약 간의 두드러진 차이점에 초점을 맞춥니다. 초점은 스마트 계약 및 스크립팅 기능에 있기 때문에 플랫폼 또는 블록체인의 기본 사항은 여기서 논의하지 않습니다. 또한 이 문서에서는 온체인 스마트 계약과 RSK와 같은 몇 가지 2계층 스마트 계약 솔루션의 존재를 소개합니다. 이러한 솔루션은 확실히 논의할 가치가 있으며 공간 때문에 매우 심층적인 연구를 수행하지 않을 것입니다.

보조 제목

이더리움: 자체 상태가 있으며 튜링 완료

이미지 설명

그림: EVM 수수료 구조

각 트랜잭션은 사용된 opcode에 따라 상당한 양의 Gas를 소비합니다. 가스비는 이더리움 고유의 암호화폐인 ETH로 지불합니다. 이러한 노드가 블록당 수행해야 하는 계산량을 제한하기 위해 "블록 가스 제한"이라고 하는 단일 블록에서 사용할 수 있는 가스의 양에 대한 제한이 있습니다.

스마트 계약 기능을 실행하는 동안 계약은 필요한 데이터를 저장하고 액세스할 수 있습니다. 용도에 따라 이러한 데이터는 다른 위치, 즉 다른 데이터 위치에 저장될 수 있습니다. 첫 번째는 계산에 사용된 값을 포함하는 "스택"입니다. 스택의 처음 16개 항목만 쉽게 액세스할 수 있으므로 장기 보관에 적합하지 않습니다. 스택을 사용한 계산은 다음과 같습니다.

이미지 설명

그림: 스택 기반 컴퓨팅

둘째, 스택을 보완하기 위해 "계약 메모리"를 사용하여 현재 계약 실행 중에 데이터를 저장, 검색 및 전달할 수 있습니다. 이 값은 스택에서 계산에 사용하기 위해 메모리에서 검색할 수 있으며 결과는 다시 메모리에 저장됩니다. 이 값은 현재 실행 기간 동안만 지속됩니다. 계약 실행이 끝나면 계약 메모리와 스택이 지워집니다.

궁극적으로 데이터가 있는 곳은 계약 실행 중에 데이터를 유지하는 데 사용되는 "계약 저장소"입니다. 토큰 잔액과 같은 영구 변수는 계약 저장소에 저장됩니다. 데이터 지속성을 위해 계약 메모리는 각 이더리움 노드에 저장됩니다. 따라서 메모리는 RAM과 같고 스토리지는 하드 드라이브 또는 영구 데이터베이스와 같습니다.

Ethereum Virtual Machine의 작동 방식에 대한 자세한 내용은 MyCrypto의 기사에서 확인할 수 있습니다.

스마트 계약 작성 모든 스마트 계약이 EVM을 사용하지만 대부분의 스마트 계약은 대부분의 JVM 바이트코드가 손으로 작성되지 않은 것처럼 EVM 바이트코드를 사용하여 손으로 작성되지 않습니다. 대신 Ethereum에서 스마트 계약을 작성하는 데 사용할 수 있는 몇 가지 고급 언어가 있으며 가장 인기 있는 것은 Solidity이지만 EVM 지향 프로그래밍 언어인 Vyper도 있습니다. 아래 이미지에는 매우 간단한 Solidity 스마트 계약의 예가 포함되어 있습니다.

이렇게 배포된 계약은 네트워크에 EVM 바이트코드의 "조각"으로만 존재하며 자체적으로는 거의 사용할 수 없습니다. 이들과 "인터페이스"하려면 모든 공용 기능 및 해당 매개변수 목록을 포함하는 ABI(Application Binary Interface)를 제공해야 합니다. 사용자가 이러한 계약을 더 잘 알 수 있도록 Etherscan과 같은 서비스는 사용자가 계약을 사용하기 전에 코드를 검사할 수 있도록 계약 소스 코드를 확인하는 데 도움이 됩니다.

모든 스마트 계약은 Ethereum 노드에 연결하고 JSON-RPC 인터페이스를 사용하여 직접 액세스할 수 있습니다. 그러나 많은 스마트 계약은 노드에 연결하고 ABI를 관리하는 프런트 엔드 애플리케이션을 통해 액세스됩니다. 이는 후드 아래에서 JSON-RPC를 호출할 수 있는 다양한 Ethereum SDK(예: web3.js 또는 ethers.js) 중 하나를 사용하여 수행할 수 있습니다. 가장 어려운 부분을 시각화하여 계약 사용자에게 더 나은 경험을 제공합니다.

스마트 계약은 호출과 트랜잭션의 두 가지 방식으로 상호 작용할 수 있습니다. 호출은 계약 기능에 대한 기본 호출이며 블록체인에 아무것도 브로드캐스트하지 않습니다. 따라서 호출 프로세스는 "읽기 전용"이며 계약 상태를 변경할 수 없으며 수수료가 발생하지 않습니다. 트랜잭션은 실제로 네트워크에 브로드캐스트되고 블록체인에 포함되며 광부 수수료를 생성하는 실제 "쓰기 작업"입니다. ERC20 토큰을 예로 들면 호출을 통해 토큰 잔액을 검색하고 트랜잭션을 시작하여 토큰을 전송합니다.

Ethereum의 이러한 속성(Turing-complete EVM 및 영구 저장소 포함)을 통해 온체인에서 실행되는 모든 유형의 분산 응용 프로그램을 만들 수 있습니다. 좋은 예는 Maker, Uniswap 및 Compound와 같은 애플리케이션과 ERC20 및 ERC721 토큰 표준을 포함하는 DeFi 생태계입니다. 이러한 애플리케이션은 동적 액터의 수에 제한이 없는 복잡한 기능을 허용합니다.

그림: rDai의 DeFi 상호 운용성

가장 중요한 것은 스마트 계약 자체가 다른 스마트 계약의 "참여자"가 되어 이러한 계약 간의 강력한 통합 및 구성을 가능하게 한다는 것입니다. 예를 들어 토큰 잔액을 보유하고 이를 Compound에 빌려주거나 Uniswap과 교환하거나 rDai를 사용하여 DAI에 자동으로 투자하고 발생한 이자를 자선 단체에 기부하는 스마트 계약이 있습니다.

스마트 계약은 서로 상호 작용할 수 있지만 온체인의 모든 트랜잭션은 외부 계정에서 가져와야 합니다. 따라서 이더리움 스마트 계약 간의 상호 작용은 여전히 ​​초기 트랜잭션을 통해 사용자에 의해 트리거되어야 합니다. 이 초기 트리거 이후 계약 간의 상호 작용은 직접 액세스와 유사합니다.

즉, 스마트 계약은 다른 스마트 계약의 "읽기 전용 기능"을 호출하거나 "쓰기 작업"(트랜잭션)을 트리거할 수 있습니다. 외부 계정만이 트랜잭션을 발생시킬 수 있기 때문에 스마트 컨트랙트 간의 트랜잭션은 사용자가 시작한 트랜잭션과 구분하기 위해 내부 트랜잭션 또는 메시지 호출이라고 합니다.

보조 제목

비트코인: 상태 비저장 및 단순성

모든 비트코인 ​​거래(일반 전송 포함)는 "비트코인 스크립트"(스크립트)라는 스택 기반 프로그래밍 언어로 지원됩니다. 위에서 언급했듯이 Ethereum의 EVM은 Turing-complete 및 상호 운용 가능한 스마트 계약을 위해 설계되었지만 Bitcoin Script는 의도적으로 다양한 제한을 추가하고 근본적으로 다른 방식으로 작동합니다. Bitcoin 스크립트를 해석하는 것은 EVM과 같으며 Bitcoin 스크립트는 스택(Stack)을 사용하여 값(Value)을 보유하고 이러한 값에 대한 계산을 수행합니다. 그러나 EVM과 달리 스택은 비트코인 ​​스크립트에서 사용할 수 있는 유일한 데이터 위치입니다. 이는 나중에 계약 실행에 사용하기 위해 여러 값을 저장하기 어렵다는 것을 의미합니다. 더 중요한 것은 계약 실행 중에 지속되는 값을 저장하거나 수정하는 것이 불가능하다는 것을 의미합니다(단, EVM은 가능함).

이것이 이더리움의 스마트 컨트랙트와 비트코인의 가장 큰 차이점입니다. 이더리움의 모델은 상태가 저장되는 반면 비트코인은 상태가 없습니다. 대중적인 이해는 이더리움이 일반적인 명령형 변경 가능 데이터 프로그래밍 패러다임과 유사하다고 생각할 수 있는 반면 비트코인은 함수 불변 데이터 패러다임과 유사하다는 것입니다.

비트코인의 모델은 트랜잭션의 독립적이고 훨씬 더 효율적인 검증을 허용하여 트랜잭션 병렬화 및 샤딩을 더 쉽게 만듭니다. 그러나 변경 가능한 데이터 저장소가 없으면 Bitcoin에서 Ethereum과 같은 복잡한 스마트 계약을 생성하기가 더 어렵습니다. 예를 들어 ERC20 계약은 토큰 잔액을 추적하고 변경해야 합니다.

이러한 상태 차이 외에도 Bitcoin 스마트 계약의 복잡성을 제한하는 다른 요소가 있습니다. 특히 Bitcoin Script는 특정 산술 함수와 모든 형태의 루핑 또는 재귀에 대한 지원이 부족합니다. 또한 해당 계약의 유효 크기 제한은 520바이트이며 최대 201개의 opcode만 포함할 수 있습니다.

비트코인에 대한 대부분의 스마트 계약은 몇 가지 단순 계약 범주에 속합니다. 예를 들어, 여러 참여자가 사용할 수 있는 다중 서명 계약 또는 해시된 시간 잠금 계약(HTLC)이 있습니다.

그리고 비트코인의 이러한 계약은 매우 간단하기 때문에 대부분의 가치는 다른 계약을 다른 오프체인 애플리케이션 로직과 결합하여 포착합니다. 이러한 방식으로 간단한 계약을 결합하여 라이트닝 네트워크 또는 교차 체인 경매와 같은 복잡한 솔루션을 만들 수 있습니다.

비트코인 트랜잭션 설명 비트코인의 모든 트랜잭션은 소위 "트랜잭션 출력"을 통해 실현됩니다. 이러한 트랜잭션 출력이 계정에서 사용 가능한 경우 이를 UTXO(사용되지 않은 트랜잭션 출력)라고 합니다. 이러한 UTXO는 잠금 스크립트(또는 scriptPubKey) 및 지정된 사용 조건에 의해 잠깁니다. UTXO를 사용하려고 할 때 잠금 해제 스크립트(또는 ScriptSig)가 제공되고 이 스크립트가 함께 계산을 수행합니다. 트랜잭션은 스크립트가 오류 없이 실행되고 결과 값이 TRUE인 경우에만 적용됩니다.

EVM과 마찬가지로 모든 비트코인 ​​노드는 트랜잭션을 확인하기 위해 이러한 스크립트를 실행하지만 비트코인 ​​블록체인에는 가스 비용의 개념이 없으므로 채굴자는 트랜잭션 데이터의 바이트당 비용을 지불합니다. 노드가 수행해야 하는 작업량을 제한하기 위해 보다 집중적인 일부 스크립트 작업에도 일부 제한이 적용되었습니다.

스마트 계약과의 상호 작용 비트코인의 스마트 계약은 P2SH 모델을 사용하여 작성됩니다(일급 창고 참고: "스크립트 해시에 대한 지불"로 번역됨). P2SH 모드의 잠금 스크립트에는 스크립트 해시가 포함되어 있으며 전체 스크립트에 대한 잠금 해제 스크립트(사용 스크립트라고 함)와 해당 사용 스크립트에 대한 잠금 해제 스크립트를 제공해야 합니다. 아래 그림은 이 패턴을 보여줍니다.

이미지 설명

그림: P2SH 모드

일류 창고 지식: P2SH 모드는 복잡한 스크립트(전통적인 메커니즘은 P2PKH)의 사용을 단순화하기 위해 도입되었으며 복잡한 잠금 스크립트는 비트코인 ​​주소가 A 20인 것처럼 20바이트 해시가 있는 간단한 스크립트로 컴파일됩니다. Base58 인코딩을 기반으로 하는 -바이트 공개 키. P2SH와 기존 P2PKH 방식의 가장 큰 차이점은 전송 조건을 설정하는 사람이 발신자에서 수신자로 변경된다는 것입니다. 상환 스크립트에 다양한 이체 조건을 추가하여 다중 서명 트랜잭션과 같은 다양한 형태의 트랜잭션을 구현할 수 있습니다.

비트코인 노드는 이러한 스마트 계약 거래를 두 단계로 검증합니다. 먼저 Redeem 스크립트가 해시되고 잠금 스크립트의 해시에 대해 확인됩니다. 일치하는 경우 "상환 스크립트"가 원래 잠금 스크립트인 것처럼 "잠금 스크립트"를 사용하여 "상환 스크립트"의 잠금을 해제합니다.

이러한 배포 차이는 두 유형의 스마트 계약을 결합하여 사용하도록 권장합니다. 좋은 예는 이더리움 및 비트코인에 대한 비수탁형 로컬 트랜잭션을 지원하는 LocalCryptos입니다. Ethereum의 경우 하나의 큰 스마트 계약을 사용하여 모든 트랜잭션을 추적하는 반면 Bitcoin의 경우 각 트랜잭션에 대해 별도의 계약을 생성합니다.

스마트 계약 작성 Ethereum에는 EVM 바이트 코드로 컴파일되는 여러 고급 언어가 있지만 Bitcoin은 이에 대해 덜 주의를 기울였습니다. 비트코인 스크립트로 구축할 수 있는 시스템의 복잡성에도 불구하고 계약 자체는 종종 단순합니다. 따라서 기본 시스템을 추상화할 필요가 거의 없습니다. 그리고 비트코인 ​​계약에는 크기 제한이 있고 추가 바이트당 비용이 높기 때문에 계약을 "가능한 한 작게" 유지하는 것이 중요합니다.

이러한 고급 언어는 Bitcoin에서 덜 중요하지만 존재합니다. Ivy는 2017년 Dan Robinson이 만든 비트코인에서 "가장 세련된" 고급 언어입니다. 아래 그림은 Ivy로 작성된 스마트 컨트랙트의 예시입니다. 이 계약은 수취인이 제 시간에 돈을 쓰지 않으면 송금인이 회수할 수 있는 돈을 보내는 데 사용할 수 있습니다.

최근 Blockstream의 여러 연구원이 기본 시스템을 추상화하는 대신 스마트 계약의 분석 및 구성 가능성에 중점을 둔 언어인 Miniscript를 출시했습니다. 비트코인 계약에 추상적인 복잡성이 부족한 경우가 많다는 점을 감안할 때 이것이 올바른 길인 것 같습니다.

보조 제목

위는 한편으로 이더리움 체인에 전적으로 존재하는 많은 강력하고 유용한 스마트 계약을 생성할 수 있는 이더리움이며 동시에 상태 저장 특성(Stateful)으로 인해 확장성 문제도 제기합니다. 반면에 비트코인의 스마트 컨트랙트 무상태(Stateless) 모델은 스마트 컨트랙트 거래에 대한 독립적이고 간단한 검증을 가능하게 하지만 그 스크립팅 시스템은 컨트랙트의 실용성을 제한합니다.

포크 이전에 비트코인 ​​캐시와 비트코인은 동일한 역사를 공유했기 때문에 기본 스크립팅 시스템은 기능적으로 동일하며 비트코인 ​​캐시는 이러한 동일한 측면에서 이점을 얻습니다. 그 이후로 비트코인 ​​캐시 커뮤니티의 많은 부분이 "더 유용한 스마트 계약"의 필요성을 인식했습니다. 비트코인 캐시는 스마트 계약을 더욱 유용하게 만드는 새로운 기능을 가능하게 하는 동시에 비트코인의 상태 비저장 검증을 허용하는 기본 속성을 유지합니다.

BCH의 기능 업그레이드 Bitcoin Cash 스마트 계약의 가능성을 이해하려면 2년마다 네트워크 업그레이드를 살펴봐야 합니다. 이러한 네트워크 업그레이드는 2017년 최초의 하드 포크 이후 매년 5월과 11월에 수행되었습니다. Schnorr 서명과 같은 몇 가지 다른 개선 사항이 있었지만 Bitcoin 스크립팅 엔진의 변경 사항에 대해 구체적으로 논의합니다.

Bitcoin 초기에는 안전하지 않은 사용으로 인해 일부 opcode가 비활성화되었습니다. 비트코인 캐시 포크 이후 1년 이내에 비트코인-ABC 노드 개발자는 이러한 문제를 해결하고 아래 다이어그램에 표시된 것처럼 약간 수정된 기능으로 opcode를 다시 도입했습니다. 가장 중요한 점은 업그레이드를 통해 비트코인 ​​스크립트에서 구조화된 데이터를 인코딩 및 디코딩할 수 있다는 것입니다.

이미지 설명

그림: BCH는 2018년 5월에 새로운 opcode를 활성화했습니다.

반년 후, 2018년 11월 비트코인 ​​캐시 네트워크 업그레이드에서 또 다른 새로운 opcode가 출시되었습니다. 그중에는 OP_CHECKDATASIG 업데이트가 있어 사용자가 비트코인 ​​스크립트의 모든 메시지 서명을 확인할 수 있습니다. 2018년에 도입된 스크립트 업데이트를 결합하면 이러한 업데이트를 사용하여 Bitcoin Cash에 새롭고 유용한 스마트 계약 기능을 도입할 수 있습니다.

스마트 계약 작성 Bitcoin Cash의 새로운 기능은 원래 Bitcoin 스크립트에 비해 스마트 계약에 많은 추가 복잡성을 추가합니다. 따라서 고급 언어, SDK 및 도구를 통해 고급 추상화 계층을 제공하는 에코시스템을 갖추는 것이 더욱 중요합니다.

현재 이 문제에 대해 작업 중인 두 개의 큰 프로젝트는 Spedn(Tendo Pein이라는 가명으로 생성)과 CashScript(이 기사의 저자 Rosco Kalis가 생성했으며 Ethereum의 Solidity 언어에서 영감을 얻음)입니다. 아직 활발하게 개발 중이지만 이러한 도구를 사용하면 비트코인 ​​캐시에서 스마트 계약을 더 쉽게 사용할 수 있습니다. 일부 기능은 CashScript 코드 스니펫을 사용하여 아래에 설명되어 있습니다.

이에 대한 예는 아래의 HODLVault 예시 계약에서 볼 수 있습니다. 이 계약은 특정 BCH/USD 가격에 도달할 때까지 HODLing을 시행합니다. 필요한 BCH/USD 가격 피드는 오라클 공급자가 게시하고 사용자가 계약으로 전달합니다. 분산화를 추가하기 위해 단일 중앙 집중식 서비스를 신뢰하는 대신 여러 데이터 소스를 사용하도록 스마트 계약을 설정할 수 있습니다.

Covenants 두 번째 큰 사용 사례는 Covenants라는 기술로, 개체의 사용을 제한하기 위해 재산법에서 사용되는 용어에서 이름을 따왔습니다. Bitcoin Cash의 경우 스마트 계약에서 통화 사용을 제한합니다. 따라서 비트코인의 스마트 계약은 일반적으로 금전적 지출만 승인할 수 있는 반면, 비트코인 ​​캐시 계약은 지출할 수 있는 금액이나 수령인의 신원에 제한을 둘 수 있습니다.

비트코인을 전송할 때 발신자는 트랜잭션을 승인하기 위해 서명을 제공해야 합니다. 이 서명을 생성하기 위해 발신자는 트랜잭션의 해시 표현에 서명합니다. 이 해시를 Sighash라고 하며 실제 트랜잭션 데이터는 Sighash 프리이미지에 포함됩니다.

동일한 서명으로 _OP_CHECKSIG_ 및 _OP_CHECKDATASIG_를 사용하여 Sighash 데이터에 액세스할 수 있습니다. 데이터 형식은 사양에서 확인할 수 있으며 아래 이미지에 포함되어 있습니다. 중요한 필드는 스마트 계약 자체의 바이트 코드를 포함하는 scriptCode입니다. 다른 하나는 사용자가 트랜잭션 출력을 강제할 수 있는 hashOutputs입니다.

이미지 설명

그림: Bitcoin Cash Sighash 데이터 형식

보증 계약이 기술적인 수준에서 어떻게 작동하는지 아는 것이 좋지만 CashScript는 이미 계약과 관련된 대부분의 복잡성을 추상화합니다. CashScript를 사용하여 스마트 계약을 작성할 때 Sighash 원본을 확인하고 해독하는 수동 단계 없이 이러한 필드를 쉽게 사용할 수 있습니다.

보장 계약 기술을 사용한 최초의 스마트 계약은 사용자가 사망한 사람의 재산을 자신의 재산으로 이전할 수 있는 스마트 계약인 Licho's Last Will입니다. 계약은 세 가지 다른 기능을 정의합니다. 첫 번째는 후계자가 180일 후에 자금을 청구할 수 있도록 허용합니다. 두 번째는 소유자의 콜드 키(ColdKey)를 어떤 식으로든 사용할 수 있도록 허용합니다. 세 번째는 전체 계약 잔액을 계약으로 되돌려 보내도록 하여 소유자의 핫 키가 180일 기간을 새로 고칠 수 있도록 합니다.

Last Will의 CashScript 버전이 아래에 포함되어 있지만 원래 버전은 Spedn이 작성했으며 여기에서 볼 수 있습니다.

이것은 유용한 보증 계약의 간단한 예 중 하나이지만 보증 계약은 훨씬 더 복잡한 기능을 가능하게 합니다. Last Will 계약이 체결된 후 작성자 Karol Trzeszczkowski는 계속해서 Patreon 등에서 반복 지불을 시행하는 회사인 Mecenas를 만들었습니다.

보장된 계약은 원래 새로운 opcode _OP_CHECKOUTPUTVERIFY_가 필요한 "Bitcoin Covenants"라는 제목의 논문에서 제안되었습니다. _OP_CHECKTEMPLATEVERIFY_ 또는 _OP_CHECKSIGFROMSTACK_과 같은 다른 제안이 이어졌습니다. 후자는 Bitcoin Cash의 언약 구현과 매우 유사합니다. 보증 계약에 대한 자세한 내용은 Tendo Pein의 기사에서 확인할 수 있습니다.

시뮬레이션된 상태는 "마지막 유언장" 계약을 살펴봅니다. 계약이 체결되면 상속인을 변경하는 것이 유용할 수 있습니다. 현재 컨트랙트의 바이트코드를 보고 현재 컨트랙트로 강제로 보낼 수 있기 때문에 이 바이트코드를 약간 변경하여 약간 다른 컨트랙트로 강제로 전송할 수 있습니다. 전체 계약의 잔액을 바이트코드는 같지만 상속인이 다른 계약으로 보내는 함수를 만들 수 있습니다.

이 기술을 사용하면 계약의 동일한 규칙을 유지하면서 계약의 특정 변수를 변경할 수 있습니다. Ethereum과 같은 상태 저장 시스템의 확장성 문제 없이 계약 상태의 이점 중 일부를 제공하기 때문에 "시뮬레이션된 상태"라고 합니다. 이 접근 방식은 어딘가에서 절충해야 하므로 다른 단점이 있습니다.

결론적으로

바이트코드 내에서 이러한 변수를 교체하는 것은 번거롭게 느껴질 수 있으며, 특히 바이트코드 내부의 더 깊은 변수를 교체하려고 할 때 그렇습니다. 이 기능은 새 매개변수를 제공하여 새 바이트코드가 자동으로 생성되도록 고급 언어로 추상화해야 합니다. 이 추상화는 다음과 같습니다.

미래를 바라보다

많은 추상화가 더 큰 계약 비용으로 발생하여 더 높은 수수료가 발생합니다. 그러나 비트코인 ​​캐시의 거래 수수료는 일반적으로 낮기 때문에 두 가지 모두에서 최고입니다. 그러나 비트코인 ​​캐시는 비트코인과 동일한 크기 제한이 있으므로 이러한 추상화로 인해 제한 내에서 유지하기가 더 어렵습니다. 이로 인해 많은 개발자가 컴파일된 바이트코드를 수동으로 최적화해야 했습니다.

결론적으로

모든 암호 화폐는 스마트 계약 시스템에서 무게가 나갑니다. Ethereum은 가장 광범위한 기능을 갖춘 가장 일반적으로 사용되는 스마트 계약 플랫폼입니다. 비트코인은 상태 비저장 스크립팅 시스템을 통해 보다 기본적인 버전의 스마트 계약을 제공합니다. 이 시스템은 검증이 더 효율적이지만 기능이 떨어집니다. 비트코인 캐시는 비트코인과 동일한 기반을 가지고 있지만 효율적인 검증과 유용한 스마트 계약 사이에서 타협을 시도하는 새로운 기능을 추가합니다. 결국 모두 비슷한 목표를 향해 나아갑니다.