EOSEVM 아키테처 심층 분석

 

EOS EVM(Ethereum Virtual Machine)은 EOS 커뮤니티내에서 많은 기대를 받고 있는 릴리즈입니다.

EVM 프로젝트는 1년이 넘는 기간동안 준비해 왔으며, 생태계 전반에서 기여자들을 참여한 대규모 프로젝트였습니다.

2023년 4월 14일에 메인넷 베타(0.4)가 출시될 예정이며, 개발은 마지막 단계에 접어들었습니다.

 

EOS EVM 런칭 로드맵 확인

 

EOS EVM이 활성화되면 EOS는 다른 생태계의 수많은 새로운 개발자와 프로젝트에 노출될 것입니다. EOS EVM은 기존 Solidity 환경과의 호환성 및 기능 패리티를 유지하면서도 시장에서 가장 뛰어난 EVM

성능을 제공하기 위해 구성되어 있습니다.

 

이 핵심 생태계 인프라에 대한 자세한 정보는 EVM 개발자들과의 최근 토론을 확인하세요.

 

• EOS EVM 요약
  • EVM은 Ethereum Virtual Machine의 약자로, 이더리움 생태계에서는 Solidity로 작성된 탈중앙화 애플리케이션(dApp)을 배포하고 실행할 수 있도록 스마트 컨트랙트 시리즈가 제공됩니다.
  • EOS EVM은 EOS 스마트 컨트랙트내에 포함되어 EOSEVM이 Ethereum EVM과 같은 방식으로 작동할 수 있습니다.
  • EOS EVM은 다른 EVM과 기능적으로 동등하지만, 비교할 수 없는 속도, 성능 및 호환성을 제공합니다. 이러한 성능은 EOS 네이티브의 강력한 특성과 설계 아키텍처 설계를 통해 가능했습니다.

 

• EOS EVM: 이더리움 활성화 도구

  • EOS가 처음 출시되었을 때 많은 사람들이 EOS를 이더리움을 대체할 ‘이더리움 킬러’로 관심을 가졌지만, 이는 EOS의 목적이 아니었으며 EOS EVM이 출시되어도 저희의 생각은 변하지 않습니다. 대신 EOS EVM은 이더리움 인에이블러가 되어 Solidity 개발자가 프로젝트 내에서 비교할 수 없는 확장성에 액세스할 수 있도록 합니다.
  • Antelope.io에서 지원하는 EOS 네이티브의 전체 기능은 아직 탐구되고 있습니다. 따라서 해당 계층에서 차세대 Web3 애플리케이션을 구축할 수 있는 많은 새로운 개발의 기회가 있습니다. 그러나 이러한 성장의 기회는 양날의 검과도 같습니다. 현재 dApp 개발자가 네이티브 레이어에서 빠르게 시작하고 실행할 수 있는 적절한 도구, 교육 리소스 및 인프라가 부족합니다.
  • 반면, 이더리움 네이티브 언어인 Solidity는 Web3 산업의 중요한 기반 요소가 되었습니다. 2015년 최초 출시 이후 이더리움 생태계 내에서 성장하고 있는 수많은 오픈 소스 도구, 튜토리얼, 프로젝트 및 개발자가 있습니다. 따라서 새로운 개발자도 Solidity 라이브러리에 액세스하여 Web3 개발의 요령을 배우고 빠른 구축을 시작할 수 있습니다.
  • EOS EVM의 출시와 함께 개발자들은 EOS 기술 스택의 강력한 성능과 이더리움 커뮤니티의 액세스 가능한 리소스를 결합하여 두 가지 장점을 모두 누릴 수 있게 되었습니다. 따라서 EOS에서 Solidity 개발을 가능하게 하는 것이 네트워크의 대량 채택을 위한 다음 주요 단계입니다.

 

• 대량 채택에서 EOS 네이티브의 역할

  • 현재 EOS EVM에 중점을 두고 있지만, EOS의 기본 레이어는 여전히 ​​생태계의 주력 제품입니다. 다가오는 Leap v4.0.0 릴리스와 함께 EOS 네이티브는 EOS EVM과 함께 지속적으로 혁신될 것입니다.
  • EOS 네이티브는 속도와 강력한 라이브러리로 인해 기존 개발자들 사이에서 인기 있는 언어인 C++로 작성되었습니다. 운영 체제 및 게임과 같이 엄격한 성능 요구 사항이 있는 기술 프로젝트에서 자주 사용됩니다.
  • 이 기본 아키텍처로 인해 EOS 네이티브에 구축된 스마트 컨트랙트는 훨씬 더 효율적이고 강력하며 Web2 또는 기타 전통적인 컴퓨터 과학 분야에서 진입하는 개발자들이 선호하는 경우가 많습니다. GameFi가 부상하면서 EOS 네이티브는 이미 Web2 환경에서 구축하고 있던 게임 개발자들이 필요에 따라 Web3 요소를 원활하게 통합할 수 있도록 함으로써 채택을 위한 강력한 벡터로 남아 있습니다.
  • EOS 네이티브에 대한 인프라 작업이 계속되고 Ethereum 생태계의 현재 도구가 EOS EVM에서 출시됨에 따라 다른 생태계에서는 불가능했던 혁신의 기회가 나타날 것입니다. 이를 염두에 두고 EOS는 포지티브섬 개발 환경으로 자리잡고 있습니다. Web3 베테랑 또는 입문자들이 리소스를 조정하고 협업하여 혁신할 수 있는 완벽한 장소입니다.

• EOS EVM의 기술적 세부사항

  • 성능과 사용 편의성을 극대화하기 위해 EOS EVM 내부에서 많은 일이 진행되고 있습니다. 다음은 작년에 구현된 몇 가지 혁신적인 디자인 선택 중 일부입니다.
• Silkworm 아키텍처
  • 출시 일정 변경에 기여한 주요 아키텍처 개선 사항은 EOS EVM의 실행 클라이언트로 Silkworm을 구현한 것입니다. Silkworm은 Erigon 사양에 따라 Ethereum 노드를 C++로 구현한 것입니다. RPC를 지원하고 이 영역에서 호환성을 높이는 데 사용되고 있습니다.
  • 디자인의 목표는 코드의 성능이나 가독성을 희생하지 않고 가장 빠른 이더리움 클라이언트가 되는 것입니다. 다음은 EtherWorld의 기사에서 소개된 Silkworm의 주요 특징입니다.
    • 코드 베이스가 새롭고 주요 레거시 기능이 포함되어 있지 않으므로 Silkworm를 이해하기가 더 쉽습니다.
    • 개발자 커뮤니티에서는 중립적인 분위기입니다.
    • Silkworm는 Apache-2.0 라이선스에 따라 라이선스가 부여됩니다. 이 라이센스는 허용적이며, 제한이 가장 적으며 대부분의 프로젝트에서 사용할 수 있습니다.
    • Silkworm은 이미 가장 빠르고 완벽하게 호환되는 EVM 구현으로 알려진 EVM 인터프리터로 evmone을 사용합니다.
    • Silkworm은 완전한 ACID 트랜잭션이 포함된 가장 빠른 임베디드 키-값 저장소인 MDBX를 사용합니다.
• 이 아키텍처 설계의 주요 이유 중 하나는 확장 가능하고 생태계의 다른 영역과 완벽하게 호환되는 방식으로 RPC 요청을 처리하는 것입니다. 개발자와 사용자는 온체인 데이터를 쿼리하거나 새로운 트랜잭션을 생성하기 위해 EVM 환경의 최신 상태에 액세스할 수 있는 방법이 필요합니다. 여기에서 RPC가 작동합니다.
• EVM 트랜잭션은 EVM 컨트랙트에 의해 EOS 블록체인에서 먼저 처리됩니다. 그 후 별도의 Silkworm 기반 EVM 노드에 의해 EOS 블록체인에서 추출되어 재처리되므로, 노드는 EVM 환경의 상태 보기를 컨트랙트에서 볼 수 있는 것과 동기화하여 볼 수 있습니다. 이 상태는 RPC 노드가 MetaMask 지갑과 같은 클라이언트의 표준 RPC 요청을 처리할 수 있도록 합니다.
• RPC 노드를 EOS 블록체인을 처리하는 Leap 노드와 분리된 RPC 노드를 유지하고, 클라이언트의 RPC 요청이 많은 경우 확장을 위해 새로운 RPC 노드 인스턴스를 생성할 수 있습니다. EVM 상태만 추적하면 되는 각 추가 RPC 노드는 모든 EOS 상태 추적을 담당하는 훨씬 적은 수의 Leap 노드로부터 EOS 블록을 간단히 공급받을 수 있습니다.
• 또한 EOS EVM에서 대체 노드 구현이 아닌Silkworm을 사용하는 주요 이점은 EVM 컨트랙트와 RPC 요청을 처리하는 노드 간에 많은 핵심 코드를 공유할 수 있다는 것입니다. 이를 통해 두 환경 간의 비호환성 위험이 줄어듭니다. Silkworm은 C++로 구현되기 때문에 WebAssembly로 컴파일하고 EVM 컨트랙트 내에서 실행하는 것이 간단했습니다. 두 환경 간의 호환성을 유지함으로써 동일한 코드를 공유하는 것이 매우 중요한 이점이였으며, 특히 EOS EVM 내에서 신뢰성이 보장되는 브리지와 같은 맞춤 기능을 지원하기 위해 Silkworm 코드에 추가적인 변경이 필요했을 때 이점이 더욱 크게 나타났습니다.
• 이 모든 것을 염두에 두고 이로 인한 지연에도 불구하고 Silkworm으로의 마이그레이션은 EOS EVM의 중요한 측면이 되었습니다.

 

• 크립토 기본 요소(Crypto Primitives)

  • 현재 Web3 환경에서 중요한 논의는 사용자 개인 정보 보호입니다. 더 많은 엔터프라이즈 애플리케이션이 진입함에 따라 개인 정보 보호 기술 구현이 더욱 중요해 집니다. 이로 인해 최근까지 EOS에서 실행할 수 없었던 zk-SNARKS와 같은 툴링에 대한 인기가 높아졌습니다.
  • Leap 3.1 하드 포크가 발생했을 때 Antelope 프로토콜에 Crypto Primitives 기능이 도입되어 이 기능과 다른 복잡한 작업을 지원할 수 있는 새로운 기능을 사용할 수 있습니다. 이 기능은 모든 EOS 컨트랙트에서 새로운 호스트 기능을 사용할 수 있도록 하며, 이더리움 암호화 프리컴파일과 일대일로 매핑합니다.
  • 이더리움 생태계는 이미 이러한 기능을 많이 갖추고 있으며 이론적으로 실행할 수 있습니다. 그러나 비싼 개스피과 느린 트랜잭션은 기술적, 경제적 장애물로 이어질 수 있습니다. EOS EVM을 사용하면 이러한 장벽이 사라지고 개발자는 다른 환경에서 실행하기 어려운 라이브러리를 실험할 수 있습니다.
  • zk-SNARKS를 위한 기능을 EOS EVM으로 가져오는 것 외에도 개발자는 이제 네이티브 EOS 레이어에서 동일한 프리미티브를 활용할 수 있습니다. 이는 EOS EVM과 함께 EOS 네이티브 채택에 다시 한 번 중요한 역할을 할 것입니다.

 

• 1 초 블록 시간

  • 앞서 언급했듯이 성능과 호환성은 EOS EVM 개발에서 중요한 고려 사항이었습니다. 이 두가지 모두 EVM 블록 시간을 결정할 때 고려해야 할 사항입니다. EOS 네이티브는 0.5초의 블록 시간을 자랑하지만 EOS EVM 블록 시간은 1초입니다. 이는 ~12초의 Ethereum 블록 시간보다 훨씬 빠르며 디자인이 1초보다 짧게 설계할 경우 손실될 수 있는 호환성을 유지합니다.
  • 0.5초 블록 시간은 이론상 1초보다 빠르지만 실제로는 더 복잡합니다. 첫째, 여기에서 논의된 메트릭은 처리량이 아닌 대기 시간입니다. EOS EVM은 선택한 블록 시간에 관계없이 EOS 블록체인이 지원하는 높은 처리량의 이점을 얻습니다. 둘째, 실제로 트랜잭션 전송에서 블록에 포함된 확인을 받는 데까지 관찰되는 실제 대기 시간은 블록 시간을 1초에서 0.5초로 줄인다고 해서 단순히 절반으로 줄어드는 것이 아닙니다. 대기 시간 감소는 그보다 덜 중요합니다. 따라서 블록 시간을 1초에서 0.5초로 줄이면 성능이 약간 향상되지만 설계의 호환성 측면에서 상당한 손실이 발생할 수 있습니다.
  • 이는 이더리움 사양에 따라 블록 시간 간격이 결정되기 때문에, 현재 블록 타임스탬프를 반환하는 EVM opcode는 초 단위의 해상도만 지원합니다. 이는 EOS 블록이 EVM 블록에 일대일 블록 매핑을 위해서, 타임스탬프를 잘라내고 두 개의 연속된 블록에 동일한 타임스탬프를 전송해야합니다.
  • 서로 다른 블록에 걸쳐 타임스탬프를 복제하면 큰 피해의 발생을 막을 수 있지만, 기존 Solidity 컨트랙트가 EVM과 인터페이스하는 방식이 중단되기 때문에 설계상 위험이 될 수 있습니다. EOS EVM을 개발할 때, Ethereum에서 온 개발자들이 네이티브 체인과 최대한 유사한 경험을 할 수 있도록 하는 것이 중요했습니다. 따라서 호환성 손상이 가장 적은 블록 시간을 선택했습니다.
  • 또한 이 설계를 통해 네이티브 및 EVM 블록 시간을 모두 분리할 수 있습니다. 이는 향후 EOS 네트워크가 블록 주기를 변경하더라도 EVM 런타임에 영향을 미치지 않는다는 것을 의미합니다. 이와 관련하여 업그레이드 계획은 없지만, 개발자들은 EOS EVM을 기반으로 구축된 dApp이 향후 EOS 네트워크 아키텍처의 변경 사항과 호환될 것이라고 확신할 수 있습니다.

 

• 투자금을 모금하고, 구축을 시작하고, 출시를 준비하세요!

  • EOS EVM은 가장 널리 채택된 EVM 중 하나가 되어, EOS에서 이더리움 개발자들에게 새로운 기회를 제공할 것입니다. 이는 주로 이 기사에서 설명한 다음과 같은 아키텍처 선택 덕분입니다:
    • RPC를 지원하는 Silkworm의 C++ 구현으로 노드가 클라이언트의 RPC 요구 사항을 충족하도록 확장할 수 있습니다.
    • Leap 3.1과 함께 도입된 Crypto Primitives 아키텍처는 EOS EVM 및 EOS 네이티브 모두에서 zk-SNARKS 및 기타 복잡한 계산을 가능하게 합니다.
    • 1초의 블록타임으로 뛰어난 성능을 제공하고, EOS EVM과 기존 Ethereum EVM 간의 호환성을 최대한 유지합니다.
  • 이번 주, EOS EVM은 코드 완료에 도달했으며 새로운 테스트넷은 3월 27일에 출시될 예정입니다. 메인넷이 4월 14일에 가동됨에 따라 EOS에서 구축을 시작하기에 지금보다 더 좋은 시기는 없습니다.
  • EOS EVM의 모든 발전에도 불구하고 EOS 네이티브에서는 작업 속도가 느려지지 않습니다. 실제로 현재 EVM에 필요한 리소스가 줄어들면서 핵심 프로토콜 개발자는 EOS 네이티브에 더 많은 관심을 기울일 수 있습니다. 이를 통해 EOS 네이티브는 EOS 네트워크의 주력 제품으로서의 역할을 하는 동시에 Solidity 프로젝트가 EOS가 제공하는 모든 이점을 활용할 수 있습니다.
  • EOS EVM 기반, EOS 네이티브를 기반 구축에 상관없이 프로젝트를 빠르게 시작하고 실행하는 데 도움이 되는 리소스와 자금이 있습니다. 여기에서 EOS 생태계의 자금 조달 기회에 대해 자세히 알아보시기 바랍니다. 현재 테스트넷에 연결하는 방법에 대한 자세한 내용은 EOS EVM에 대한 마지막 기사를 확인하시기 바랍니다. 이후 EOS Documentation 및 EOS Learn Portal로 이동하여 EOS에서 dApp을 구축하고 배포하는 방법에 대한 지침을 확인시기 바랍니다.

 

세부 내용 확인: EOS EVM Architecture Deep Dive

https://eosnetwork.com/blog/eos-evm-architecture-deep-dive/