작성자: 피터
머리말
2009년 BTC의 등장 이후 세 번의 기술적 반복을 거쳐온 비트코인은 단순한 디지털 네이티브 자산 개념에서 복잡한 기능과 응용을 갖춘 분산형 금융 시스템으로 발전했습니다.
이 글은 BEVM의 창업자가 BTC 기술의 진화에 대한 자신의 통찰을 공유하고, BTC Layer2 기술 발전의 핵심 이정표인 BEVM이 어떻게 BTC의 미래를 기술 수준에서 구현하는지 자세히 설명합니다. 분산된 생태적 번영.
이 기사를 통해 다음 사항에 대해 자세히 알아볼 수 있습니다.
- BTC Layer2의 필요성
- BTC Layer2를 구현하는 방법은 무엇입니까?
- 완전히 분산된 BEVM 솔루션
BTC 탄생 이후 세 가지 위대한 혁명적 기술 반복에 경의를 표합니다.
- 2009년: 처음으로 블록체인 구조를 사용하여 분산화폐 애플리케이션을 개방하는 BTC가 탄생했습니다.
- 2017: BTC Segregated Witness는 최대 4MB의 저장 공간을 지원하도록 업그레이드되어 BTC의 온체인 저장 문제를 해결했습니다. 이는 또한 현재 널리 사용되는 Ordinals 프로토콜(자산 발행)의 기초를 제공합니다.
- 2021: BTC Taproot는 완전히 분산된 BTC Layer2 기술에 대한 기본 지원을 제공하는 BTC 임계값 서명 알고리즘을 지원하도록 업그레이드되었습니다.
1. BTC Layer2를 구축하려는 이유는 무엇입니까?
1. 수요가 있습니다. 비트코인 네트워크는 자산 등록 수요를 충족하지만 여전히 온체인 결제(레이어 2)가 필요한 자산이 많이 있습니다.
현재 ETH의 Layer2는 ETH Layer1의 복사본일 뿐이며 Layer1에서 해결할 수 없고 Layer2에서 해결해야 하는 실제 비즈니스 문제를 해결하지 못합니다.
ETH Layer2는 ETH Layer1의 문제를 해결합니다. Layer2는 Layer1의 높은 가스 비용 문제를 해결합니다. GMX와 같은 ETH의 가장 큰 Layer 2 Arbitrum에 대한 파생 상품 애플리케이션이 생성된 것은 바로 이러한 요구 때문입니다.
BTC의 Layer2는 ETH의 Layer2만큼 관련성이 없습니다.
BTC의 비튜링 완전 온체인 가상 머신은 자산을 등록할 수만 있고 결제는 할 수 없기 때문에 BTC Layer1은 BTC Layer1에서 발행한 자산을 결제하기 위해 Turing Complete BTC Layer2를 요구해야 합니다.
2. 가능함: BTC는 완전히 분산된 레이어 2가 될 수 있습니다.
2021년 BTC Taproot 업그레이드 이전에는 완전히 분산된 BTC Layer2를 달성하는 것이 불가능합니다. 그러나 이번 업그레이드 이후 BTC 임계값 서명 알고리즘을 통해 BTC는 완전히 분산된 레이어 2 컴퓨팅 계층을 지원할 수 있습니다.
둘째, 분산형 BTC L2를 달성하는 방법은 무엇입니까?
비트코인 개선 제안(BIP)은 비트코인에 새로운 기능과 정보를 소개하는 설계 문서인 반면 탭루트 업그레이드는 Schnorr Signature(BIP 340), Taproot(BIP 341) 및 Tapscript(BIP 342)의 세 가지 BIP를 편집한 것입니다. 세 가지 업그레이드를 통칭하여 BIP Taproot라고 합니다.
이는 비트코인에 보다 효율적이고 유연하며 비공개적인 전송 방법을 제공할 것이며, 그 핵심은 슈노르 서명과 메르켈 추상 구문 트리를 사용하는 데 있습니다.
이는 비트코인에 보다 효율적이고 유연하며 비공개적인 전송 방법을 제공할 것이며, 그 핵심은 슈노르 서명과 메르켈 추상 구문 트리를 사용하는 데 있습니다.
Schnorr 서명은 단순성과 보안으로 잘 알려진 디지털 서명 체계입니다. Schnoor 서명은 계산 효율성, 저장 및 개인 정보 보호 측면에서 여러 가지 이점을 제공합니다.
사용자는 공개키를 통해 서명자의 신원을 확인하고, 데이터를 통해 계약 내용을 확인함으로써 디지털 계약의 유효성을 검증한다.
Schnorr 집계 서명은 여러 서명 데이터를 단일 집계 서명으로 압축하고 병합할 수 있습니다.
검증자는 서명과 관련된 모든 데이터와 공개키 목록을 통해 하나의 집합적 서명을 검증하고, 검증에 성공하면 관련된 모든 서명과 모든 통과를 독립적으로 검증하는 것과 동일한 효과를 낸다.
현재 대부분의 블록체인은 ECDSA 다중 서명 알고리즘을 사용하는데, 블록 데이터의 경우 각 노드는 자신의 개인 키를 사용하여 독립적인 디지털 서명을 생성하고 이를 다른 노드에 브로드캐스팅합니다. 다른 노드는 서명을 확인하고 이를 다음 데이터 블록에 기록합니다.
이 방법을 사용하면 합의 노드 수가 많을 때 각 합의 블록 라운드에 저장되는 서명 데이터가 계속 증가하여 저장 공간을 차지하게 됩니다.
새로운 노드가 네트워크에 합류하고 기록 블록을 동기화해야 할 때마다 대량의 서명 데이터가 네트워크 대역폭에 큰 문제를 야기합니다.
통합 서명 기술을 사용한 후, 각 노드는 그림 2와 같이 다른 노드에서 브로드캐스트한 통합 서명 명함을 수집한 다음 서명을 조각으로 통합하여 저장합니다.
이런 방식으로 새로운 노드가 합류할 때 과거 블록을 동기화하려면 집계된 서명 데이터를 다운로드하기만 하면 되며, 이는 네트워크 대역폭 점유를 크게 줄이고 거래 수수료를 줄입니다.
또한 키 집계를 통해 모든 Taproot 출력이 유사하게 보입니다. 다중 서명 출력, 단일 서명 출력 또는 기타 복잡한 스마트 계약이 모두 블록체인에서 동일하게 보이므로 많은 블록체인 분석을 사용할 수 없으므로 모든 Taproot 사용자의 개인 정보가 보호됩니다.
MAST(Merkle Abstract Syntax Tree)는 Merkle 트리를 사용하여 리프가 Schiller 비중복 스크립트(예: 다중 서명 또는 시간 잠금)인 복잡한 잠금 스크립트를 암호화합니다.
MAST(Merkle Abstract Syntax Tree)는 Merkle 트리를 사용하여 리프가 Schiller 비중복 스크립트(예: 다중 서명 또는 시간 잠금)인 복잡한 잠금 스크립트를 암호화합니다.
지불 시 관련 스크립트와 해당 스크립트에서 Merck 트리 루트까지의 경로만 공개됩니다. 그림 3과 같이 script1을 사용하려면 script1, script2, hash3만 공개하면 됩니다.
MAST의 주요 이점은 다음과 같습니다.
- 복잡한 지급 조건 지원
- 실행되지 않은 스크립트나 실행되지 않은 지불 조건을 공개할 필요가 없어 더 나은 개인정보 보호를 제공합니다.
- 압축된 트랜잭션 크기: 스크립트 수가 증가함에 따라 비 MAST 트랜잭션 크기는 선형적으로 증가하는 반면 MAST 트랜잭션 크기는 대수적으로 증가합니다.
하지만 Taproot 업그레이드에는 문제가 있습니다. 즉, P2SH가 일반적인 P2PKH(Pay-to-Public-Key-Hash)와 다르게 동작하며 여전히 개인 정보 보호 문제가 있습니다.
체인에서 P2SH와 P2PKH를 동일하게 보이게 할 수 있나요?
이를 위해 Taproot는 제한된 수의 서명자가 있는 스크립트에 대해 두 부분으로 나눌 수 있는 솔루션을 제안했습니다.
첫 번째 부분은 다중 서명으로, 모든 서명자가 "협업 지출"이라고 하는 특정 지출 결과에 동의합니다.
두 번째 부분은 "비협업 지출"이라고 하며 매우 복잡한 스크립트 구조를 가질 수 있습니다.
이 두 부분은 "또는" 관계에 있습니다.
그림 3에서 볼 수 있듯이 Script3은 2/2 다중 서명으로 Alice와 Bob이 모두 서명해야 유효하며 "협력 지출"인 반면 Script1과 2는 "비협력 지출"입니다.
"협력적 지출"과 "비협력적 지출" 모두 이 산출물을 소비할 수 있으며, 그중에는 다음이 포함됩니다.
- "비협업 지출" 스크립트의 경우 위의 MAST 방법을 채택하고 MerkleRoot를 사용하여 Merkle 트리 루트를 나타냅니다.
- "협업 지출" 스크립트의 경우 Schnoor 서명을 기반으로 하는 다중 서명 알고리즘이 채택됩니다. Pa와 Pb는 각각 Alice와 Bob의 공개 키를 나타내고 Da와 Db는 각각 Alice와 Bob의 개인 키를 나타낸다고 가정합니다. 따라서 집합 공개키는 P=Pa+Pb이고, 해당 개인키는 Da+Db이다.
- "협업지출"과 "비협업지출"은 P2PKH 형태로 결합되며, 공개키는 PP+H(P||MerkleRoot)G, 해당 개인키는 Da+Db+H(P| |MerkleRoot) ).
- Alice와 Bob이 "협업 지출"에 동의하면 둘 중 한 명이 개인 키에 H(P||MerkleRoot)를 추가하는 한 Da+Db+H(P||MerkleRoot)를 사용합니다.
온체인에서는 기본 MAST를 공개할 필요 없이 공개 키와 해당 개인 키를 사용하여 P2PKH 트랜잭션처럼 작동합니다.
3. 완전히 분산된 BTC 레이어2 솔루션:
3.1 BTC 라이트 노드 + 분산 임계값 서명 계약
이 솔루션에서는 BTC 체인에서 분산 임계값 서명 집계 보관 계약을 완료하기 위해 n(n은 BEVM의 모든 검증자가 될 수 있음)의 고정 검증자를 선택합니다.
이 솔루션에서는 BTC 체인에서 분산 임계값 서명 집계 보관 계약을 완료하기 위해 n(n은 BEVM의 모든 검증자가 될 수 있음)의 고정 검증자를 선택합니다.
BEVM 레이어 2의 각 검증인의 블록 생성 개인키는 BTC의 임계값 서명 집합 개인키의 일부를 파생시키며, n개의 검증인의 임계값 개인키는 BTC의 집합 서명 사진 주소로 결합됩니다. n의 최대값 범위는 1000 이상일 수 있습니다.
- 사용자 A가 BTC를 BEVM에 크로스체인하려는 경우 사용자는 BTC를 비트코인 집계 보관 계약으로 보내기만 하면 되며 사용자는 BEVM 레이어 2에서 BTC를 받을 수 있습니다.
- 이에 따라 사용자 A가 출금 작업을 수행하면 집계된 서명을 구성하는 n개의 검증 노드 중 m개만이 분산 임계값 서명 계약 상호 운용을 자동으로 완료하고, 커스터디 계약에서 사용자 A로의 전송이 비트코인에서 완료되면 완료될 수 있습니다. , BTC는 BEVM에서 파괴됩니다.
3.2 BTC를 기본 가스 수수료 및 EVM 호환 레이어 2로 구현
1) EVM 원리
Ethereum Virtual Machine은 Ethereum 스마트 계약을 위한 런타임 환경입니다. 샌드박스 처리되었을 뿐만 아니라 실제로는 완전히 격리되어 있습니다.
이는 EVM에서 실행되는 코드가 네트워크, 파일 시스템 및 기타 프로세스에 액세스할 수 없음을 의미합니다. 스마트 계약 간의 접근도 제한됩니다.
이더리움의 최하위 계층은 EVM 모듈을 통해 계약의 실행 및 호출을 지원하며, 호출 시 계약 주소에 따라 계약 코드를 획득하고 EVM에 로드하여 실행합니다. 일반적으로 스마트 계약의 개발 프로세스는 Solidity를 사용하여 논리 코드를 작성한 다음 컴파일러를 통해 바이트코드로 컴파일하고 최종적으로 Ethereum에 게시하는 것입니다.
2) EVM의 주요 부분
3) EVM 코드
EVM 코드는 Ethereum Virtual Machine 코드로, Ethereum이 포함할 수 있는 프로그래밍 언어의 코드를 나타냅니다. 계정과 연결된 EVM 코드는 해당 계정으로 메시지가 전송될 때마다 실행되며, 저장소를 읽고 쓰는 기능과 메시지 자체를 보내는 기능을 가지고 있습니다.
4) 기계 상태
Mchine State는 프로그램 카운터, 스택 및 메모리를 포함하여 evm 코드가 실행되는 곳입니다.
5) 보관
스토리지는 읽기, 쓰기, 수정이 가능한 영구 저장 공간이며, 각 컨트랙트가 데이터를 지속적으로 저장하는 장소이기도 합니다. 스토리지는 총 2256개의 슬롯으로 구성된 거대한 맵이며, 각 슬롯은 32바이트를 갖습니다.
6) BTC를 가스비로 사용
스토리지는 읽기, 쓰기, 수정이 가능한 영구 저장 공간이며, 각 컨트랙트가 데이터를 지속적으로 저장하는 장소이기도 합니다. 스토리지는 총 2256개의 슬롯으로 구성된 거대한 맵이며, 각 슬롯은 32바이트를 갖습니다.
6) BTC를 가스비로 사용
비트코인 네트워크에서 전송된 BTC를 EVM에서 거래 실행을 위한 가스비 계산 통화로 사용하도록 합니다.
모든 댓글