'병렬 EVM'이 이더넷 EVM 생태계의 생존을 위한 싸움인 이유는 무엇인가요?

저자: Haotian, 독립 연구원 출처: X, @tmel0211

최근 패러다임은 Monad에 2억 2500만 달러 규모의 자금 조달에 막대한 투자를 단행했습니다. 패러다임은 최근 모나드에 2억 2,500만 달러 규모의 펀딩을 주도하며 '병렬 EVM'에 대한 뜨거운 관심을 불러 일으켰습니다. 그렇다면 "병렬 EVM"은 어떤 문제를 해결할 수 있을까요? 병렬 EVM 개발의 병목 현상과 핵심은 무엇일까요? 제 생각에 "병렬 EVM"은 고성능 레이어1 체인을 충족시키기 위한 EVM 체인의 마지막 전투이자 이더넷 EVM 생태계의 생존을 위한 전투입니다.

이더넷 EVM은 가상 머신을 "직렬화"할 수 있기 때문에 가상 머신을 "직렬화"하는 것이 아니라 가상 머신을 "직렬화하는" 것이 EVM 개발의 핵심입니다.

EVM은 '직렬'로만 트랜잭션할 수 있기 때문에 EVM 호환 레이어1 체인과 EVM 호환 레이어2 체인은 모두 기본적으로 상태 및 트랜잭션 최종성을 처리하는 동일한 프레임워크를 기반으로 하기 때문에 성능 제약이 적용됩니다."

그러나 솔라나, 수이, 앱토스 등과 같이 고성능에 중점을 둔 레이어1은 본질적으로 병렬화가 가능하다는 장점이 있습니다. 이러한 맥락에서 고성능 레이어1 퍼블릭 체인의 영향력에 맞서 싸우기 위해서는 본질적으로 부족한 '병렬' 기능을 보완할 필요가 있습니다. 어떻게 할까요? 기술적 원칙과 세부 사항을 포함하여, 저는 설명을 시작하기 위해 EVM의 새로운 체인인 @Artela_Network를 예로 들어 설명하겠습니다:

1) 강화된 EVM 레이어1 체인의 대표로 모나드, Artela, SEI 등을 병렬화할 것입니다. EVM과의 호환성을 기반으로 TPS를 크게 향상시키고 제안된 EVM 환경에서 트랜잭션에 병렬화 기능을 제공할 수 있습니다. 이러한 독립적인 병렬 EVM layer1 체인은 독립적인 합의 메커니즘과 기술적 특성을 가지고 있지만 여전히 EVM 생태계와의 호환성 및 확장을 목표로 하며 이는 "혈통을 변경"하는 방식으로 EVM 체인을 재구성하고 EVM 생태계에 서비스를 제공하는 것과 동일합니다.

2) 이클립스, 메가ETH 등으로 대표되는 확장된 레이어2 EVM 호환 체인은 레이어2 체인의 독립적인 합의 및 거래 "전처리" 기능을 활용하며, 대량 거래가 BSE에 의해 차단될 경우 체인이 "전처리기"로 사용될 수 있도록 합니다. EVM은 대량의 트랜잭션이 메인 네트워크에 일괄 처리되기 전에 트랜잭션 상태를 필터링하고 처리할 수 있으며, 다른 체인의 실행 계층을 선택하여 트랜잭션 상태를 최종적으로 확정할 수 있습니다. 이는 EVM을 플러그 가능한 실행 모듈로 추상화하여 필요에 따라 최적의 "실행 레이어"를 선택할 수 있어 병렬 기능을 실현하는 것과 같지만, 이러한 방식은 EVM을 지원할 수 있지만 EVM 프레임워크의 범위를 벗어납니다.

3) Polygon, BSC 등이 EVM을 지원하는 가장 좋은 솔루션입니다. Polygon, BSC 등은 동등한 Alt-layer1 체인의 대표로서 EVM의 병렬 처리 능력을 어느 정도 달성하지만 최적화의 알고리즘 계층 만 수행하고 최적화의 심층 합의 계층 및 저장 계층을 수행하지 않았으므로 이러한 유형의 병렬 기능은 특정 기능에 가깝다고 볼 수 있으며 EVM의 병렬성 문제를 완전히 해결하지 못합니다.

4) 앱토스, 수이, 퓨얼 등은 차이형 비 EVM 병렬 체인의 대표주자로, 어떻게 보면 EVM 체인의 구현이 아니라 태생적으로 높은 동시 실행 용량 접점을 가지고 있으며, 일종의 미들웨어나 코딩 및 파싱을 통해 EVM 환경과 호환되는 것입니다. 환경이 필요합니다. 이더넷 레이어2인 Starknet의 경우, Cario 언어와 계정 추상화로 인해 병렬성을 가지고 있지만 EVM과의 호환성을 위해서는 특별한 파이프라인이 필요합니다. 이는 기본적으로 이러한 비 EVM 체인이 EVM 체인과의 병렬성에서 겪는 문제와 동일합니다.

위 네 가지 옵션은 각각 고유한 초점을 가지고 있습니다. 예를 들어 병렬성을 갖춘 레이어2는 "실행 계층" 체인을 모듈식으로 결합하는 유연성에 초점을 맞추고, EVM 호환 체인은 특정 기능을 위한 커스터마이징을 강조합니다. 다른 비 EVM 체인의 경우, EVM 호환 기능은 이더의 유동성을 끌어올리는 데 더 중점을 두며, EVM 생태계를 완전히 통합하고 병렬성을 근본부터 바꾸는 것을 목표로 하는 향상된 EVM 레이어1 트랙은 하나만 남아 있습니다.

향상된 병렬 EVM 레이어1 퍼블릭 체인을 만들기 위한 핵심은 무엇일까요? 어떻게 하면 EVM 체인을 리팩터링하면서도 EVM 생태계에 서비스를 제공할 수 있을까요? 두 가지 핵심 사항이 있습니다.

1, 상태 I/O 디스크에 액세스하여 정보를 읽고 출력하는 기능으로 인해 데이터를 읽고 쓰는 데 시간이 소모되고 단순한 트랜잭션 정렬 및 스케줄링만 가능하며 병렬 처리 능력을 근본적으로 개선할 수 없지만 캐시, 데이터 슬라이싱 및 분산 스토리지 기술까지 도입해야 할 필요성이 있습니다.

2) 효율적인 네트워크 통신, 데이터 동기화, 알고리즘 최적화, 가상 머신 강화, 연산과 IO 작업의 분리 등 합의 메커니즘 수준에서 다양한 구성 요소의 최적화 등을 통해 기본 구성 요소 아키텍처, 협업 프로세스 등 전신을 다음 단계로 이동시켜야 합니다. 기본 구성 요소 아키텍처, 협업 프로세스 및 기타 포괄적 인 최적화 및 개선 측면, 궁극적으로 신속한 대응 능력, 컴퓨팅 소비 제어 가능, 병렬 트랜잭션의 높은 정확도에 기여합니다.

병렬 EVM layer1 체인 프로젝트 자체와 관련하여 프레임 워크의 어떤 기술 혁신과 최적화를 달성하기 위해? "병렬 EVM"?

아르텔라는 기본 아키텍처 계층에서 리소스 조정 및 최적화의 "병렬 EVM" 기능을 완벽하게 실현하기 위해 Elastic Computing과 Elastic Block Space를 도입했습니다. Elastic Computing과 Elastic Block Space, 어떻게 이해하나요? Elastic Computing은 네트워크가 수요와 부하에 따라 컴퓨팅 리소스를 동적으로 할당하고 조정할 수 있도록 하고, Elastic Block Space는 네트워크의 트랜잭션 수와 데이터 크기에 따라 블록 크기를 동적으로 조정할 수 있도록 하며, 전체 탄력성 설계는 트래픽의 흐름을 자동으로 감지하는 쇼핑몰의 에스컬레이터처럼 작동합니다. 왼쪽;"> 앞서 말했듯이 상태 I/O 디스크 읽기 성능은 "병렬" 능력을 달성하기 위해 알고리즘을 통해 EVM, 폴리곤, BSC 및 기타 EVM 호환 체인을 병렬화하는 데 매우 중요하며 2-4 배의 개선 효율성을 달성 할 수도 있지만 알고리즘 최적화, 합의 계층, 스토리지 계층은 더 깊은 수준의 최적화, 합의 계층, 스토리지 계층, 합의 계층 및 스토리지 계층이 없습니다. 그러나 이는 알고리즘 수준에서만 최적화되고 합의 수준이나 스토리지 수준에서는 최적화되지 않으므로 진정한 심층 최적화는 어떤 모습일까요?

이에 대해 Artela는 데이터베이스 기술 프로그램을 차용하여 읽기 및 쓰기 상태가 개선된 상태에서 쓰기 전 로깅(WAL) 기술로 가기 전에 쓰기 상태가 변경되어 로그에 기록되고 메모리에 제출되는 첫 번째 변경 기록에 쓰여질 상태가 변경되면 완료되었다고 생각할 수 있습니다. "쓰기"작업은 실제로 디스크 쓰기 작업에 즉시 쓸 때 변경 상태의 쓰기를 피하기 위해 비동기 작업을 수행하여 디스크의 I / O 작업을 줄입니다. 상태 읽기 역시 기본적으로 비동기 작업이며, 컨트랙트 히스토리를 기반으로 다음 특정 컨트랙트 호출에서 어떤 상태가 사용될지 예측하여 미리 메모리에 로드하는 사전 로드 전략을 통해 읽기 효율을 개선하여 디스크 I/O 요청의 효율성을 향상시킵니다.

요약하면 메모리 공간과 실행 시간을 교환하는 알고리즘으로, EVM VM의 병렬 처리 기능을 근본적으로 개선하고 상태 충돌 문제를 근본적으로 최적화하는 것입니다.

이 외에도 Artela는 복잡성을 더 잘 관리하고 개발 효율성을 개선하기 위해 Aspect 모듈식 프로그래밍 기능을 도입하고, 프로그래밍 유연성을 향상하기 위해 WASM 코드 파싱을 도입했으며, 실행 계층의 안전한 격리를 가능하게 하는 기본 API 액세스 기능을 갖추고 있습니다. 이를 통해 개발자는 Artela 환경에서 스마트 컨트랙트를 효율적으로 개발, 디버그 및 배포할 수 있으며, 개발자 커뮤니티를 위한 맞춤형 확장성을 활성화할 수 있습니다. 특히 개발자는 스마트 컨트랙트 코드 레이어에서 병렬화 방향으로 코드를 최적화하도록 장려하는데, 이는 각 스마트 컨트랙트의 호출 로직과 알고리즘이 상태 충돌 가능성을 줄이는 데 매우 중요하기 때문입니다.

초당 10,000건의 트랜잭션을 처리할 수 있다고 주장하는 "병렬 EVM"의 개념은 본질적으로 트랜잭션 상태의 실행 과정을 최적화하는 것임을 알기란 어렵지 않습니다. 기술적 핵심은 전용 데이터베이스, 개발자 친화성, 합의의 지연 실행, 슈퍼스칼라 파이프라인 기술 등을 통해 대규모 트랜잭션 병렬 처리에 도달하는 것으로, 로직의 본질인 연산 탄력성 및 I/O 비동기적 특성에서 Artela와 크게 다르지 않습니다.

그러나 제가 정말 말하고 싶은 것은 이러한 유형의 고성능 병렬 EVM 체인은 실제로 웹2의 제품과 기술을 통합한 결과이며, 트래픽이 많고 수시로 부하가 많은 웹2의 성숙한 애플리케이션 시장에서 사용되는 '기술적 처리'를 채택하고 있다는 점입니다.

먼 미래를 내다본다면, '병렬 EVM'은 웹2.0 기반 인프라를 위한 EVM 생태계의 다음 단계이며, 자본 시장의 영향을 받을 수 있습니다. 강세도 의미가 있습니다.