Arbitrum의 최근 업데이트에는 Stylus VM 업그레이드가 포함되어 있으며 다음과 같은 몇 가지 향상된 기능을 자랑합니다.
이러한 개선은 클라우드 네이티브 환경 내에서 수많은 이점으로 유명한 WASM 통합에서 비롯됩니다. WASM의 역할에 대한 자세한 내용은 다음 섹션에서 다루겠습니다.
Arbitrum은 WASM을 체인에 도입했지만 그렇게 하는 첫 번째 플랫폼은 아닙니다. Polkadot은 이전에 WASM 스마트 계약 생성을 허용했습니다. 이를 위해 임베디드 DSL과 유사한 어셈블리 스크립트와 잉크라는 Rust에서 영감을 받은 언어라는 두 가지 언어를 제공합니다!
마찬가지로 Cosmos는 스마트 계약 실행을 위해 CosmWasm을 활용합니다. 개발자는 여기에서 Rust를 사용하여 스마트 계약을 작성할 수 있습니다.
WASM에 대한 친화력 블록체인을 탐색하기 전에 WASM을 선택하는 Cosmos와 Polkadot의 이론적 근거를 검토해 보겠습니다.
Cosmos는 다음과 같은 장점을 지닌 WASM을 홍보합니다.
Polkadot의 WASM 런타임은 다음과 같은 기능을 보여줍니다.
Polkadot, Cosmos 및 Arbitrum은 WASM으로 인한 여러 가지 이점을 공유합니다. 그러나 Arbitrum에는 Cosmos의 세부 사항과 함께 나중에 논의할 독특한 제품이 있습니다.
WASM이 무엇인지, 그리고 그 이면에 있는 동기를 살펴보겠습니다.
WebAssembly(WASM)는 이진 명령어 형식입니다. 특히 웹 브라우저 내에서 기본 애플리케이션과 비슷한 속도로 코드를 실행할 수 있습니다. C 및 Rust와 같은 언어의 컴파일 대상으로 속도, 효율성 및 보안에 최적화되어 있습니다. WASM은 웹 성능을 크게 향상시키고 웹 기능을 확장합니다.
WASM은 브라우저와 같은 JavaScript 환경 내에서 작동하므로 웹과 밀접하게 연결되어 있습니다. 이러한 환경 내에서 개발자는 WASM API뿐만 아니라 완전한 웹 API 지원에 대한 전체 액세스 권한을 갖습니다. 이 컨트롤을 통해 개발자는 웹 상호 작용을 미세 조정할 수 있습니다.
WASM의 개념은 코드를 한 번 작성하여 어디에서나 실행할 수 있다는 이상을 중심으로 전개됩니다.
2016년에는 프로그램에 DSL(도메인 특정 언어)을 통해 새로운 기능이 자주 도입되었습니다. DSL을 만드는 데는 유지 관리, 효율성 및 안전의 균형이 필요했습니다. 업계에서는 이러한 측면을 타협하지 않고 수많은 서버에 기능을 배포할 수 있는 방법을 모색했습니다.
다양한 솔루션을 면밀히 조사했는데 각각 고유한 과제가 있었습니다.
WASM이 솔루션으로 등장했습니다. WASM 컴파일러 개발이 시작되었고, 2018년에는 다양한 아키텍처와 장치 전반에 걸친 범용 코드 호환성 개념이 확장되었습니다. Java와 달리 목표는 안전을 타협하지 않는 것이었습니다.
2019년에는 언어 간 상호 운용성을 위해 WASM 모듈을 향상시키는 구성 요소 모델이 도입되었습니다. 예를 들어 이러한 혁신을 통해 다양한 언어에 적용 가능한 범용 HTTP 라이브러리를 생성하여 복잡한 문제를 혁신적으로 해결할 수 있었습니다.
WASM은 다음과 같은 인상적인 기능을 자랑합니다.
WASM 커뮤니티는 다양한 프로그래밍 언어 전반에 걸쳐 통합과 성능을 적극적으로 향상시키고 있습니다.
WASM의 잠재력과 블록체인에서의 사용을 탐구하면 Arbitrum Stylus의 한계로 돌아갑니다.
스타일러스 작동 방식을 간략하게 설명하면 다음과 같습니다.
ArbWasm
프리컴파일의 compileProgram
메소드를 통해 바이트코드는 보안, 가스 계량을 위한 계측을 거쳐 검증기의 하드웨어에 맞게 조정된 네이티브 코드로 컴파일됩니다. 이 단계는 성능과 보안을 강화하는 데 중요합니다.
추가로 보이는 세 번째 단계는 실제로 매우 중요합니다. WASM 코드를 기본 기계어 코드로 변환하면 실행 속도가 빨라집니다. 게다가 이 추가된 컴파일 단계는 "컴파일 폭탄"을 방지하는 데 도움이 됩니다.
"컴파일 폭탄"은 컴파일 중에 시스템 리소스를 소진하여 잠재적으로 컴파일러를 충돌시키거나 정지시키도록 설계된 악성 코드입니다. 이는 소프트웨어 개발 프로세스를 방해하기 위한 서비스 거부 공격으로 작동합니다.
Stylus는 C++ 및 Rust를 포함하도록 Arbitrum의 개발자 커뮤니티를 확장했습니다. 그러나 아직은 오늘날 가장 널리 퍼진 개발자 커뮤니티를 포괄하지 못하고 있습니다. 브라우저에서 스마트 계약 실행을 용이하게 하지만 아직 JavaScript 및 Python을 지원하지 않습니다.
Python과 JavaScript를 WASM에 연결하려는 초기 단계의 프로젝트가 있습니다. 그러나 가비지 수집 및 성능 문제의 복잡성으로 인해 널리 채택될 준비가 되어 있지 않습니다.
Stylus는 현재 SDK를 통해 C/C++ 및 Rust를 지원합니다. 이러한 SDK는 해당 언어의 도구와 호환됩니다. 또한 기본 암호화와 같은 타사 라이브러리의 통합도 허용합니다. 주요 제약은 이러한 라이브러리와 관련된 가스 비용입니다.
Rust SDK는 초기 단계에 있으므로 일부 기능이 부족합니다. C SDK는 ABI를 사용한 내보내기 기능을 지원하지 않습니다. 또한 두 SDK 모두 수정자 사용을 지원하지 않습니다.
현재 스타일러스에는 로컬 테스트 환경이 없습니다. 개발자는 SDK 내에서 테스트를 수행하는 것이 좋습니다. 테스트넷은 Stylus에서 스마트 계약을 실행하기 위한 유일한 옵션입니다. 그러나 테스트넷은 아직 스마트 계약 검증을 구현하지 않았습니다.
Uniswap V2 와 같은 다양한 ERC 토큰과 플랫폼을 Stylus로 포팅하는 작업이 진행 중입니다.
DSL(도메인별 언어), eDSL(내장형 DSL) 또는 일반 프로그래밍 언어 중에서 선택하는 것은 어렵습니다. 개발자는 유연성을 제한할 수 있는 더 높은 수준의 추상화가 제공하는 사용 편의성과 제어를 위해 "금속에 가까운" 작업의 이점을 비교해야 합니다.
새로운 DSL을 만들려면 도구 체인과 생태계를 개발하는 데 시간이 필요합니다. 일반 프로그래밍 언어의 하위 집합인 eDSL은 동일한 의미 체계와 구문을 유지합니다. 이를 통해 개발자는 기존 언어와 도구를 사용할 수 있어 학습 과정을 단순화할 수 있습니다. eDSL은 또한 범용 코드와의 더 나은 상호 운용성을 제공합니다. 예를 들어 JavaScript 또는 Python용 eDSL은 대규모 개발자 커뮤니티를 참여시키는 데 전략적으로 적합합니다.
일반 프로그래밍 언어는 개발을 위해 SDK를 사용해야 합니다. 이는 도구 레이어를 추가하고 장황함을 높이며 표현력을 감소시킵니다. 또한 API 호출 시간이 길어지고 개체 작업이 복잡해질 수도 있습니다.
올바른 언어를 선택하고 eDSL을 만드는 것은 이상적인 절충안이 될 수 있습니다. 인기 있는 커뮤니티에서 개발자를 끌어들이고 사용자 친화적인 도구를 제공할 수 있습니다. 현재 데이터에 따르면 이더리움 커뮤니티는 암호화폐 개발자 중에서 가장 큰 커뮤니티로 남아 있습니다. 하지만 러스트를 스마트 컨트랙트에 활용하는 폴카닷(Polkadot), 코스모스(Cosmos), 솔라나(Solana) 같은 생태계 역시 상당수의 개발자를 끌어들이며 빠른 성장을 경험하고 있다.
WASM은 실행 속도를 크게 향상시키고 번들 크기를 줄일 수 있는 잠재력을 가지고 있습니다. Stylus는 메인넷에 배포되지 않았지만 다른 네트워크의 벤치마크는 유용한 참고 자료로 사용됩니다.
이러한 벤치마크에서는 실행 시간이 4~8배 줄어들 수 있고 컴파일 크기가 절반으로 줄어들 수 있음을 나타냅니다.
스타일러스는 계약 크기를 압축하지 않은 상태에서 약 128KB로 제한합니다. 이러한 제약으로 인해 Solidity와 같은 언어에서 Stylus로 대규모 스마트 계약을 마이그레이션하는 것이 어렵습니다. 이러한 제한은 Stylus 코드베이스 내에서 명백하게 드러납니다.
// arbos/programs/programs.go const MaxWasmSize = 128 * 1024 // Maximum WASM size allowed const initialFreePages = 2 // Number of initial free pages const initialPageGas = 1000 // Gas cost for an initial page const initialPageRamp = 620674314 // Adjusts for a target size cost const initialPageLimit = 128 // Maximum number of pages allowed const initialInkPrice = 10000 // Ink price per EVM gas const initialCallScalar = 8 // Scalar for call cost
WASM은 시작 및 종료 시 약간의 오버헤드를 발생시킨다는 점에 유의하는 것이 중요합니다. 매우 가벼운 작업의 경우 EVM이 WASM보다 비용 효율적일 수 있습니다.
EVM과 WASM은 동일한 스토리지 슬롯과 상태 트리를 사용합니다. 스타일러스는 WASM 내에서 EVM API를 구현하여 EVM과의 상호 운용성을 달성합니다. 이 통합은 WASM에서 널리 채택된 호스트 I/O 모드를 활용합니다. 다음은 WASM에서 지원되는 EVM API의 전체 목록으로, 포괄적인 상호 운용성 지원을 나타냅니다.
read_args write_result storage_load_bytes32 storage_store_bytes32 call_contract delegate_call_contract static_call_contract do_call create1 create2 do_create read_return_data return_data_size emit_log account_balance account_codehash evm_gas_left evm_ink_left block_basefee block_coinbase block_gas_limit block_number block_timestamp chainid contract_address msg_reentrant msg_sender msg_value native_keccak256 tx_gas_price tx_ink_price tx_prigin memoery_grow console_log_text console_log console_tee
사용자 정의 사전 컴파일은 혁신적인 개념입니다. 그들은 실행 비용을 줄이면서 고급 암호화 기본 요소를 온체인에 통합할 수 있는 잠재력을 가지고 있습니다. 예를 들어, 텐서 계산을 사전 컴파일하여 온체인 기계 학습 비용을 줄일 수 있습니다. 그러나 현재 코드베이스에는 사용자 정의 사전 컴파일 기능에 대한 증거가 없습니다. EVM용 사전 컴파일이 존재하지만 스왑 가능하도록 설계되지 않았습니다.
WASM의 기능을 활용하여 이러한 기능이 아직 개발 중일 가능성이 높습니다. 이를 통해 EVM은 WASM으로 작성된 함수를 호출한 다음 기계어 코드로 컴파일할 수 있습니다.
재진입을 지원하지 않는 CosmWasm의 액터 모델과 달리 Stylus의 Rust SDK에는 재진입이 선택적 기능으로 포함되어 있습니다. 기본적으로 이 기능은 꺼져 있습니다. 개발자는 계약에서 재진입을 활성화할 수 있습니다.
재진입을 활성화하면 개발자가 호출 중에 저장소 캐시를 지우고 다른 안전 조치를 고려해야 하므로 API에 영향을 미칩니다. 이 예방 조치는 재진입 호출과 관련된 잠재적인 취약점을 방지하는 데 필수적입니다.
WASM은 클라우드 네이티브 도메인에서 인기를 얻고 있으며 많은 블록체인이 스마트 계약 실행을 위해 이를 채택하고 있습니다. Arbitrum이 이 통합의 선구자는 아니지만 구현은 매우 큰 영향을 미칠 수 있습니다. WASM은 블록체인 환경을 완전히 점검하거나 EVM을 대체할 수 있는 위치에 있지 않습니다. 그러나 이는 새로운 zk-롤업에 대한 Arbitrum의 우위를 높일 수 있습니다. Arbitrum의 용어 "EVM+"는 이 시나리오를 적절하게 설명합니다. EVM은 스마트 계약 플랫폼의 기반을 마련하고 WASM은 Arbitrum에 추가적인 성능 향상을 제공할 수 있습니다.