핵심요약 – Layer 2 시스템용으로 설계된 모든 기능을 갖춘 EVM 호환 실행 환경인 OVM을 구축했습니다. 이 게시물은 OVM이 이더리움 메인 체인과 동일한 롤업을 가능하게 하는 방법을 설명합니다.

OVM을 구축하는 이유는 무엇입니까?

우리 팀의 많은 사람들은 이전에 계약을 지원하는 최초의 일반화된 플라즈마 구성인 plapps를 설계하기 위해 일했습니다 ! 그러나 plapps에는 제한된 "단어" 계약과 관련된 완전히 새로운 개발자 도구가 필요했습니다. 이더리움 L2는 단순히 이더리움을 사용하여 확장하는 것을 의미하는 것이 아니라 이더리움 자체를 확장하는 것을 의미합니다 .

이것은 결국 이더리움 스마트 계약의 전체 기능 세트를 확장성 환경으로 가져오겠다고 약속한 최초의 L2 구성인 Optimistic Rollup을 개발하게 했습니다 . Unipig.exchange는 처음으로 이 전례 없는 기능을 시연했습니다. 처음으로 Uniswap은 L2에 있었습니다. 그러나 Unipig는 여전히 롤업의 힘을 활용하기 위해 L2 체인용으로 설계된 맞춤형 스마트 계약을 작성해야 했습니다. 개발자 경험을 보존하려면 더 나은 것이 필요했습니다.

OVM이란 무엇입니까?

OVM은 레이어 2 시스템에서 사용하도록 구축된 완전한 기능을 갖춘 EVM 호환 실행 환경입니다. 이를 통해 이더리움 메인 체인처럼 보이고 느끼고 작동하는 롤업 체인을 구현할 수 있습니다. Solidity에서 계약을 작성하고 Web3 API를 통해 체인과 상호 작용합니다!

OVM을 사용하면 dApp을 L2로 이동하기로 한 결정은 더 이상 아키텍처가 아닙니다. 단순히 배포의 문제입니다. 긴밀한 결합 및 구성 가능성을 포함하여 dApp 변경 사항을 구축하는 데 다른 것은 없습니다. 새로운 스마트 계약을 OVM 체인에 마음대로 배포할 수 있습니다. 즉, 머니 레고는 여전히 매력처럼 맞습니다.

그렇다면 이 마법은 어떻게 작용할까요? 그리고 OVM을 달성하기 어려웠던 이유는 무엇입니까? 다이빙하자!

문제 설명: EVM-in-EVM

모든 낙관적 L2 계획의 기초는 분쟁입니다. 플라즈마에서 롤업에 이르기까지 핵심 속성은 "낙관적 실행"입니다. 기본적으로 한 사람(또는 사람들)은 "이봐 L1, 이러한 트랜잭션을 실행할 필요가 없습니다. 결과는 X입니다!"라고 주장할 수 있습니다. 결과가 X가 아닌 경우 다른 당사자는 메인 체인에서 트랜잭션을 실행하여 잘못되었음을 증명하기 위해 비용을 지불할 수 있습니다.

행복한 경우에는 트랜잭션을 체인에서 실행할 이유가 없습니다. 이것이 낙관적 실행이 전체 처리량을 확장하는 이유입니다. 그러나 안타까운 경우(예: 위의 경우) 트랜잭션을 재생할 수 있어야 합니다tx2 . 그렇지 않으면 안전하지 않습니다!

Unipig용으로 작성된 사용자 지정 코드는 기본적 으로 execute_L2_tx(). Unipig의 경우 호출할 수도 있습니다 execute_uniswap_tx()!

물론 우리가 정말로 원하는 것은 L1 사기 방지 트랜잭션 내에서execute_EVM_tx() 일반적인 L2 이더리움 트랜잭션을 실행할 수 있는 기능 입니다 ! 결과적으로 이더리움 트랜잭션을 서로 중첩시키는 것은 매우 까다롭습니다. 특히 L2 트랜잭션이 처음부터 L1 체인을 위한 것이 아니었을 때 더욱 그렇습니다!

EVM-in-EVM이 어려운 이유

그러나 우리가 구축한 고유한 솔루션인 OVM에 대해 알아보기 전에 이것이 왜 문제가 됩니까? EVM은 EVM 트랜잭션을 실행하기에 완벽한 장소가 아닙니까? 결국 EVM 입니다 !

순진한 솔루션: L2 계약을 L1에 재배포

본질적으로 EVM은 일련의 컴퓨터 명령 과 이러한 각 명령이 트랜잭션 중에 수행해야 하는 작업을 정의합니다. 이러한 지침을 함께 모아놓은 추악한 집합체를 스마트 계약이라고 합니다. SafeMath.sol예를 들어 다음은 Solidity 라이브러리가 배포되기 전에 컴파일되는 명령의 작은 샘플입니다 .

L1에서 L2 트랜잭션을 실행하려면 L2 트랜잭션에서 사용하는 코드(일명 스마트 계약)를 L1에 가져와야 합니다. 이를 수행하는 가장 간단한 방법은 계약을 L1에 재배포하는 것입니다!

작동하지 않는 이유: 다른 체인, 다른 결과

경우에 따라 이 접근 방식이 실제로 작동 합니다 . 예를 들어 라이브러리는 기본적으로 , 등의 SafeMath수학 연산만 수행하는 간단한 계약입니다 . L2 계약을 L1에 재배포하면 L2와 동일하게 작동합니다! 결국 어떤 체인에서 발생하든 추가는 추가입니다.add()subtract()SafeMath

그러나 다른 계약의 경우 상황이 빠르게 무너집니다. 예를 들어, 현재 이더리움 타임스탬프에 42를 더한 값을 반환하는 이 간단한 계약을 생각해 보십시오.

계약 TimeShifter { 
   function getShiftedTime() returns(uint) { 
      return block.timestamp + 42; 
   } 
}

이 계약은 사기 증거를 위해 L1에 재배포할 때 동일한 결과를 반환합니까?

분명히 아닙니다! 실제로 두 개의 서로 다른 L1 블록 간에 동일한 결과를 반환하지도 않습니다! 이는 재배치된 계약이 L1 타임스탬프를 가져오기 때문입니다. 그러나 올바르게 하려면 L2 타임스탬프를 반환해야 합니다 execute_l2_tx!

더 많은 예를 통해 생각해 보면 이것이 거의 모든 스마트 계약의 문제라는 것을 금방 깨닫게 될 것입니다. 예를 들어, ERC20을 상상해 보십시오. 계약을 L1에 재배포할 때 모든 잔고를 L2에 있던 것으로 어떻게 설정합니까? 목록은 계속됩니다.

솔루션: OVM

EVM-in-EVM 문제에 대해 역사적으로 제안된 솔루션은 두 가지 접근 방식을 취했습니다. 즉, VM 자체를 분기 하거나 총알을 깨물고 Solidity에서 전체 EVM 구현을 다시 작성하는 것입니다 . OVM은 문제에 대한 새로운 접근 방식으로 더 성능이 뛰어나고 유연하며 현재 Eth 1에서 작동하며 포크가 필요하지 않습니다!

핵심적으로 OVM은 OVM 계약의 가상 컨테이너 역할을 하는 "실행 관리자"라고 하는 새로운 스마트 계약을 생성하여 이 문제를 해결합니다. Execution Manager는 다음을 포함하여 L1과 L2 간의 실행 차이로 이어질 수 있는 모든 것을 가상화합니다.

• 계약 보관

• tx.origin블록 번호, 타임스탬프 등과 같은 트랜잭션 "컨텍스트"

• 교차 계약 메시지 라우팅

기본적으로 L1과 L2 간에 약간의 차이를 보일 수 있는 EVM의 모든 기능에 대해 Execution Manager는 L1과 L2 간에 일관성을 유지하는 기능을 제공합니다.

작동 방식을 보여주는 장난감 예제로 다음과 같이 위의 타임스탬프 문제를 해결하는 컨테이너를 구성할 수 있습니다.

계약 TimestampManager { 
    uint storage ovmTimestamp; 
    
    function setOvmTimestamp(숫자: uint) { 
        ovmTimestamp = 숫자; 
    } 
    
    function getOvmTimestamp() public returns(uint) { 
        return ovmTimestamp; 
    } 
}

이제 위의 스마트 계약을 다시 만들 수 있지만 이번에는 컨테이너를 사용합니다.

계약 OvmTimeShifter { 
   function getShiftedTime() returns(uint) { 
      return timestampManager.getOvmTimestamp() + 42; 
   } 
}

이제 사기 증명 중에 L1에 컨테이너의 "가상 블록 번호"를 설정하여 올바른 값이 반환되도록 보장할 수 있습니다!

이것이 OVM이 EVM-in-EVM 실행을 가능하게 하는 방법의 핵심입니다: 체인 간에 다를 수 있는 EVM의 모든 구성 요소를 가상화합니다! 실제로 가상화해야 하는 약 15개의 이더리움 명령이 있습니다. 모든 기능을 갖춘 실제 Execution Manager를 여기에서 볼 수 있습니다 !

안전: 순도 검사기

대신 컨테이너를 호출하기 위해 위의 계약을 약간 수정해야 했습니다 block.timestamp. 이로 인해 불일치가 수정되었지만 해당 특정 계약에만 해당됩니다! L2가 안전하려면 모든 L2 계약이 block.timestamp.

이를 시행하기 위해 OVM에는 "순도 검사기"가 포함되어 있습니다. 이것은 주어진 스마트 계약이 Execution Manager를 통해서만 가상화된 명령에 액세스하는지 확인할 수 있는 기능입니다 . block.timestamp허용되지 않습니다! 이 요구 사항을 충족하지 않는 계약은 OVM에 배포되지 않도록 차단되어 임의의 계약이 위에 배포된 경우에도 L2 체인이 안전하게 유지되도록 합니다!

개발자 경험: Transpiler

계약에서 Execution Manager만 호출하도록 요구하는 또 다른 문제는 개발자 경험 block.timestamp입니다 getOvmTimestamp(). 이를 해결하기 위해 우리는 일반 EVM 바이트코드를 받아들이고 위에서 설명한 대로 컨테이너를 사용하는 OVM 바이트코드를 다시 내보내는 트랜스파일러를 구축했습니다. 이것은 개발자에게 OVM이 완전히 보이지 않는다는 것을 의미합니다. 패키지를 Waffle 또는 Truffle과 같은 선호하는 테스트 스위트에 연결하기만 solc-transpiler하면 경주가 시작됩니다!

앞으로

우리는 OVM이 이더리움 L2를 위한 중요한 진전을 나타낸다고 생각합니다. 왜냐하면 이더리움을 사용할 뿐만 아니라 이더리움을 사용할 수 있기 때문 입니다 . 단 몇 줄의 코드만으로 Solidity 계약을 더 저렴하고 빠른 솔루션으로 옮길 수 있다는 사실은 한동안 확장에 대해 가장 흥분하게 만들었습니다. 직접 해보고 싶다면 The Graph 및 Burner Wallet과 같은 표준 이더리움 도구에서 실시간으로 실행되는 Synthetix의 복잡한 교환 계약의 포트인 최신 OVM 전투 테스트를 여기에서 확인할 수 있습니다 .

더 자세히 알아보고 싶다면 설명서 , 코드 를 확인하고 discord 에 문의하세요 !

https://medium.com/ethereum-optimism/ovm-deep-dive-a300d1085f52

핵심요약 – Layer 2 시스템용으로 설계된 모든 기능을 갖춘 EVM 호환 실행 환경인 OVM을 구축했습니다. 이 게시물은 OVM이 이더리움 메인 체인과 동일한 롤업을 가능하게 하는 방법을 설명합니다.

OVM을 구축하는 이유는 무엇입니까?

우리 팀의 많은 사람들은 이전에 계약을 지원하는 최초의 일반화된 플라즈마 구성인 plapps를 설계하기 위해 일했습니다 ! 그러나 plapps에는 제한된 "단어" 계약과 관련된 완전히 새로운 개발자 도구가 필요했습니다. 이더리움 L2는 단순히 이더리움을 사용하여 확장하는 것을 의미하는 것이 아니라 이더리움 자체를 확장하는 것을 의미합니다 .

이것은 결국 이더리움 스마트 계약의 전체 기능 세트를 확장성 환경으로 가져오겠다고 약속한 최초의 L2 구성인 Optimistic Rollup을 개발하게 했습니다 . Unipig.exchange는 처음으로 이 전례 없는 기능을 시연했습니다. 처음으로 Uniswap은 L2에 있었습니다. 그러나 Unipig는 여전히 롤업의 힘을 활용하기 위해 L2 체인용으로 설계된 맞춤형 스마트 계약을 작성해야 했습니다. 개발자 경험을 보존하려면 더 나은 것이 필요했습니다.

OVM이란 무엇입니까?

OVM은 레이어 2 시스템에서 사용하도록 구축된 완전한 기능을 갖춘 EVM 호환 실행 환경입니다. 이를 통해 이더리움 메인 체인처럼 보이고 느끼고 작동하는 롤업 체인을 구현할 수 있습니다. Solidity에서 계약을 작성하고 Web3 API를 통해 체인과 상호 작용합니다!

OVM을 사용하면 dApp을 L2로 이동하기로 한 결정은 더 이상 아키텍처가 아닙니다. 단순히 배포의 문제입니다. 긴밀한 결합 및 구성 가능성을 포함하여 dApp 변경 사항을 구축하는 데 다른 것은 없습니다. 새로운 스마트 계약을 OVM 체인에 마음대로 배포할 수 있습니다. 즉, 머니 레고는 여전히 매력처럼 맞습니다.

그렇다면 이 마법은 어떻게 작용할까요? 그리고 OVM을 달성하기 어려웠던 이유는 무엇입니까? 다이빙하자!

문제 설명: EVM-in-EVM

모든 낙관적 L2 계획의 기초는 분쟁입니다. 플라즈마에서 롤업에 이르기까지 핵심 속성은 "낙관적 실행"입니다. 기본적으로 한 사람(또는 사람들)은 "이봐 L1, 이러한 트랜잭션을 실행할 필요가 없습니다. 결과는 X입니다!"라고 주장할 수 있습니다. 결과가 X가 아닌 경우 다른 당사자는 메인 체인에서 트랜잭션을 실행하여 잘못되었음을 증명하기 위해 비용을 지불할 수 있습니다.

행복한 경우에는 트랜잭션을 체인에서 실행할 이유가 없습니다. 이것이 낙관적 실행이 전체 처리량을 확장하는 이유입니다. 그러나 안타까운 경우(예: 위의 경우) 트랜잭션을 재생할 수 있어야 합니다tx2 . 그렇지 않으면 안전하지 않습니다!

Unipig용으로 작성된 사용자 지정 코드는 기본적 으로 execute_L2_tx(). Unipig의 경우 호출할 수도 있습니다 execute_uniswap_tx()!

물론 우리가 정말로 원하는 것은 L1 사기 방지 트랜잭션 내에서execute_EVM_tx() 일반적인 L2 이더리움 트랜잭션을 실행할 수 있는 기능 입니다 ! 결과적으로 이더리움 트랜잭션을 서로 중첩시키는 것은 매우 까다롭습니다. 특히 L2 트랜잭션이 처음부터 L1 체인을 위한 것이 아니었을 때 더욱 그렇습니다!

EVM-in-EVM이 어려운 이유

그러나 우리가 구축한 고유한 솔루션인 OVM에 대해 알아보기 전에 이것이 왜 문제가 됩니까? EVM은 EVM 트랜잭션을 실행하기에 완벽한 장소가 아닙니까? 결국 EVM 입니다 !

순진한 솔루션: L2 계약을 L1에 재배포

본질적으로 EVM은 일련의 컴퓨터 명령 과 이러한 각 명령이 트랜잭션 중에 수행해야 하는 작업을 정의합니다. 이러한 지침을 함께 모아놓은 추악한 집합체를 스마트 계약이라고 합니다. SafeMath.sol예를 들어 다음은 Solidity 라이브러리가 배포되기 전에 컴파일되는 명령의 작은 샘플입니다 .

L1에서 L2 트랜잭션을 실행하려면 L2 트랜잭션에서 사용하는 코드(일명 스마트 계약)를 L1에 가져와야 합니다. 이를 수행하는 가장 간단한 방법은 계약을 L1에 재배포하는 것입니다!

작동하지 않는 이유: 다른 체인, 다른 결과

경우에 따라 이 접근 방식이 실제로 작동 합니다 . 예를 들어 라이브러리는 기본적으로 , 등의 SafeMath수학 연산만 수행하는 간단한 계약입니다 . L2 계약을 L1에 재배포하면 L2와 동일하게 작동합니다! 결국 어떤 체인에서 발생하든 추가는 추가입니다.add()subtract()SafeMath

그러나 다른 계약의 경우 상황이 빠르게 무너집니다. 예를 들어, 현재 이더리움 타임스탬프에 42를 더한 값을 반환하는 이 간단한 계약을 생각해 보십시오.

계약 TimeShifter { 
   function getShiftedTime() returns(uint) { 
      return block.timestamp + 42; 
   } 
}

이 계약은 사기 증거를 위해 L1에 재배포할 때 동일한 결과를 반환합니까?

분명히 아닙니다! 실제로 두 개의 서로 다른 L1 블록 간에 동일한 결과를 반환하지도 않습니다! 이는 재배치된 계약이 L1 타임스탬프를 가져오기 때문입니다. 그러나 올바르게 하려면 L2 타임스탬프를 반환해야 합니다 execute_l2_tx!

더 많은 예를 통해 생각해 보면 이것이 거의 모든 스마트 계약의 문제라는 것을 금방 깨닫게 될 것입니다. 예를 들어, ERC20을 상상해 보십시오. 계약을 L1에 재배포할 때 모든 잔고를 L2에 있던 것으로 어떻게 설정합니까? 목록은 계속됩니다.

솔루션: OVM

EVM-in-EVM 문제에 대해 역사적으로 제안된 솔루션은 두 가지 접근 방식을 취했습니다. 즉, VM 자체를 분기 하거나 총알을 깨물고 Solidity에서 전체 EVM 구현을 다시 작성하는 것입니다 . OVM은 문제에 대한 새로운 접근 방식으로 더 성능이 뛰어나고 유연하며 현재 Eth 1에서 작동하며 포크가 필요하지 않습니다!

핵심적으로 OVM은 OVM 계약의 가상 컨테이너 역할을 하는 "실행 관리자"라고 하는 새로운 스마트 계약을 생성하여 이 문제를 해결합니다. Execution Manager는 다음을 포함하여 L1과 L2 간의 실행 차이로 이어질 수 있는 모든 것을 가상화합니다.

• 계약 보관

• tx.origin블록 번호, 타임스탬프 등과 같은 트랜잭션 "컨텍스트"

• 교차 계약 메시지 라우팅

기본적으로 L1과 L2 간에 약간의 차이를 보일 수 있는 EVM의 모든 기능에 대해 Execution Manager는 L1과 L2 간에 일관성을 유지하는 기능을 제공합니다.

작동 방식을 보여주는 장난감 예제로 다음과 같이 위의 타임스탬프 문제를 해결하는 컨테이너를 구성할 수 있습니다.

계약 TimestampManager { 
    uint storage ovmTimestamp; 
    
    function setOvmTimestamp(숫자: uint) { 
        ovmTimestamp = 숫자; 
    } 
    
    function getOvmTimestamp() public returns(uint) { 
        return ovmTimestamp; 
    } 
}

이제 위의 스마트 계약을 다시 만들 수 있지만 이번에는 컨테이너를 사용합니다.

계약 OvmTimeShifter { 
   function getShiftedTime() returns(uint) { 
      return timestampManager.getOvmTimestamp() + 42; 
   } 
}

이제 사기 증명 중에 L1에 컨테이너의 "가상 블록 번호"를 설정하여 올바른 값이 반환되도록 보장할 수 있습니다!

이것이 OVM이 EVM-in-EVM 실행을 가능하게 하는 방법의 핵심입니다: 체인 간에 다를 수 있는 EVM의 모든 구성 요소를 가상화합니다! 실제로 가상화해야 하는 약 15개의 이더리움 명령이 있습니다. 모든 기능을 갖춘 실제 Execution Manager를 여기에서 볼 수 있습니다 !

안전: 순도 검사기

대신 컨테이너를 호출하기 위해 위의 계약을 약간 수정해야 했습니다 block.timestamp. 이로 인해 불일치가 수정되었지만 해당 특정 계약에만 해당됩니다! L2가 안전하려면 모든 L2 계약이 block.timestamp.

이를 시행하기 위해 OVM에는 "순도 검사기"가 포함되어 있습니다. 이것은 주어진 스마트 계약이 Execution Manager를 통해서만 가상화된 명령에 액세스하는지 확인할 수 있는 기능입니다 . block.timestamp허용되지 않습니다! 이 요구 사항을 충족하지 않는 계약은 OVM에 배포되지 않도록 차단되어 임의의 계약이 위에 배포된 경우에도 L2 체인이 안전하게 유지되도록 합니다!

개발자 경험: Transpiler

계약에서 Execution Manager만 호출하도록 요구하는 또 다른 문제는 개발자 경험 block.timestamp입니다 getOvmTimestamp(). 이를 해결하기 위해 우리는 일반 EVM 바이트코드를 받아들이고 위에서 설명한 대로 컨테이너를 사용하는 OVM 바이트코드를 다시 내보내는 트랜스파일러를 구축했습니다. 이것은 개발자에게 OVM이 완전히 보이지 않는다는 것을 의미합니다. 패키지를 Waffle 또는 Truffle과 같은 선호하는 테스트 스위트에 연결하기만 solc-transpiler하면 경주가 시작됩니다!

앞으로

우리는 OVM이 이더리움 L2를 위한 중요한 진전을 나타낸다고 생각합니다. 왜냐하면 이더리움을 사용할 뿐만 아니라 이더리움을 사용할 수 있기 때문 입니다 . 단 몇 줄의 코드만으로 Solidity 계약을 더 저렴하고 빠른 솔루션으로 옮길 수 있다는 사실은 한동안 확장에 대해 가장 흥분하게 만들었습니다. 직접 해보고 싶다면 The Graph 및 Burner Wallet과 같은 표준 이더리움 도구에서 실시간으로 실행되는 Synthetix의 복잡한 교환 계약의 포트인 최신 OVM 전투 테스트를 여기에서 확인할 수 있습니다 .

더 자세히 알아보고 싶다면 설명서 , 코드 를 확인하고 discord 에 문의하세요 !

https://medium.com/ethereum-optimism/ovm-deep-dive-a300d1085f52