devops

이더리움의 덴쿤 하드포크의 핵심은 Proto-danksharding(프로토 댕크샤딩)인 EIP-4844다. 이는 이더리움 샤딩 로드맵에서 가장 중요한 부분이자, 롤업에서 가장 큰 비중을 차지하는 Calldata 비용을 획기적으로 줄일 수 있다. 이 업데이트에서는 blob 트랜잭션이라는 개념이 등장하는데, 관련해서 정리해 보자. Blob(Binary Large Objects) 블롭 데이터는 일반적인 트랜잭션과는 다르게 비콘 체인에서만 저장되며, 사용료가 저렴하다. 블록은 데이터 가용성을 위한 저장 공간으로, 롤업의 DA를 위해서 사용될 것으로 기대한다. 블롭은 32Byte로 구성된 4096개의 필드로 이뤄져 있으며, 블롭 한 개의 크기는 125kb로, 블록당 평균 3~6개의 블롭이 추가되면 블록당 블롭의 ..

Optimism의 op-batcher는 Layer1에 Tx Batch를 생성하여 압축, 전송하는 역할을 담당한다. 코드를 통해서 간단히 알아보자. # op-batcher func main() { oplog.SetupDefaults() app := cli.NewApp() app.Flags = flags.Flags app.Version = fmt.Sprintf("%s-%s-%s", Version, GitCommit, GitDate) app.Name = "op-batcher" app.Usage = "Batch Submitter Service" app.Description = "Service for generating and submitting L2 tx batches to L1" app.Action = cur..

L2 옵티미즘의 derivation이 어떻게 진행되는지를 정리해보려고 한다. derivation은 L2 체인을 derive하기 위해서 L1으로 부터 L2 derivation input을 읽는 과정이다. 내가 이해한 바로는 L1으로부터 필요한 정보를 가져와 L2 체인을 실행과 운영에 활용하는 것이다. 이 과정이 필요한 이유는 Layer2는 Layer1의 보안에 의존하기 때문에 트랜잭션 실행부터 Layer1 calldata 전송의 비용과 Layer2의 비용 산정, Deposit과 Withdraw를 안정적으로 진행할 수 있기 때문이다. Layer2라면 아주 중요한 파트 중 하나이며, 여기서 L2가 읽는 derivation input은 아래와 같다. L1 block attributes(block number, ..

Optimism의 Opstack은 약간의 코드 수정을 통해서 다양한 L1의 롤업을 지원할 수 있다고 생각한다. 여기서 L2의 트랜잭션 배치를 전송해야하기 때문에 L1의 정보를 derive할 필요가 있고, 그 과정을 이해해야한다. 최대한 이해할 수 있도록 정리해본다. L2 chain derivation 이는 간단히 말해서 L1의 데이터를 L2 블록으로 불러오는 것이라고 볼 수 있다. 이는 op-node(롤업노드)의 가장 중요한 역할이다. validate와 sequence하는 과정에서 L1의 데이터가 활용된다. 특히 L1의 re-org 이슈가 발생하면 L2에서 빠르게 대응해야하기 때문에 op-node의 역할이 더욱 강조된다. 각 L1 block은 L2의 시퀀싱 에포크에 맵핑되어 있다. 각 에포크 숫자는 L1..

옵티미즘의 베드락은 OP 메인넷의 주요 릴리즈 버전이다. 몇 가지 특징을 추려보자. Block Production Bedrock 버전 이후로 2초마다 새 블록을 생성한다. 기존에는 하나의 트랜잭션에 하나의 블록을 생성했었지만, 이젠 'TIMESTAMP'의 2초 간격으로 블록이 생성되며, 'BLOCKNUMBER'를 통해서 그 간격을 확인할 수 있다. System transactions Bedrock은 시스템 트랜잭션이라는 새로운 개념이 도입되었다. 시스템 트랜잭션은 op-node에 의해서 생성되는 것으로 L1 정보를 기록하여 deposit과 L2 업데이트에 활용된다. 모든 블록은 하나의 시스템 트랜잭션을 포함하며 이를 'L1 attrubutes desposited transaction'이라고 한다. 이는 ..

Opstack Transaction L2의 트랜잭션은 L1인 이더리움에 먼저 기록되어야 한다. op-batcher가 L2 트랜잭션을 L1에 전송하지만, 모든 사용자는 batcher를 우회하기 위해 L1 트랜잭션을 전송할 수 도 있다. L2의 상태 업데이트를 위해 op-geth에서 트랜잭션이 실행된다. 그 후엔 op-proposer가 새 상태의 커밋을 L1에 전송한다. L2 Transaction Process 가장 먼저 user의 Tx는 L1의 batch inbox에 전송해야하는데, 여기서 트랜잭션들을 Batch로 압축하여 L1에 포스트하는 단계가 진행된다. op-batcher는 압축률을 최대화하기 위해서 시퀀서 배치를 채널로 나눈다. 채널이 채워지거나 시간이 초과되면 채널이 압축되고 저장된다. 1) L1..

Deposit을 L1의 거래 혹은 이벤트에 의해서 트리거되는 모든 L2거래를 의미한다고 한다. Deposit Flow 대부분의 Layer2는 Layer1의 네이티브 코인을 가스비로 사용하기 때문에 이 브릿지 과정인 Deposit과 Withdraw 프로세스를 아는 것은 아주 중요하다. (Deposit에는 ETH 혹은 토큰과 같은 자산이 포함되는 것이 보통이지만, 포함되지 않을 수 도 있다) Deposit, Withdraw 프로세스는 약간 Network stack이 작동하는 방식과 유사하다. 정보가 송신의 하위 계층에서 캡슐화되고 수신 측의 같은 하위 계층에서 수신하여 어플리케이션 계층으로 올라간다. L1 프로세스 1) L1의 컨트랙트 혹은 EOA(개인 계정)은 sendMessage 함수를 이용하여 L1Cr..

요즘 다양한 Layer2 SDK가 출시되고 있지만, Optimism가 가장 많이 사용되는 것같다. 코인베이스의 BASE부터 샘알트만의 Worldcoin, BNB의 L2인 opBNB까지.. 이미 Optimistic 롤업의 표준인 만큼 롤업에 관심있는 사람들이라면 Opstack의 아키텍처를 살펴보는 것은 중요하다. (Four Pillars 미디움 글을 참고했으며, 더 이해하기 쉽게 내용을 재구성했습니다. 틀린 부분이 있다면 지적해주시길 바랍니다.) Opstack Architecture Opstack 아키텍처는 위와 같이 4가지의 요소로 나뉜다. op-node, op-geth는 Layer2에서 노드의 역할을, op-batcher, op-proposer는 Layer1에 데이터를 전송하는 시퀀서 노드 역할을 수행..

L2의 핵심 중 하나는 L1 자산의 이동이 가능한 'Bridge'다. 이 Bridge를 위한 레이어간 메시지는 L1의 컨트랙트와 L2 컨트랙트 간의 호출을 말한다. 쉽게 말해서 크로스체인 컨트랙트 콜이다. 원활한 메시지 송수신을 위해서 L1과 L2에 여러 컨트랙트를 배포해야한다. 이 컨트랙트들의 역할과 원리를 간단히 살펴보자. L1 → L2 Contract 메시지 L1에서 L2로 메시지를 전달하려면, 함수를 호출하는데, 먼저 L1의 Inbox를 거쳐서 Bridge를 거쳐야한다. 여기서 L2의 alias Account는 L1 컨트랙트의 Account다. 그래서 L2 Contact 호출하는 것은 L2 네트워크의 alias Account에서 시작하며, 호출에 의한 트랜잭션 수수료도 부과된다. L1에서 L2로 ..

Layer 2를 구축하기 위해선 L1과 동시에 몇가지 Contract를 배포해야한다. OP stack으로 테스트하는 과정에서도 먼저 L1에 여러 contract를 배포하는데, 생각보다 배포되는 게 많다. L1에 배포되는 컨트랙트는 L2와 오프체인에서 계산된 Tx, 결과값(State)가 저장되는데 주로 사용된고, L2는 L1과의 매핑 혹은 연결과 수수료에 관련된 컨트랙트들이 배포된다고 볼 수 있다. 그도 그럴 것이, L1의 보안(데이터 가용성)을 위한 컨트랙트와 이를 바라보는 L2의 증명, 확인이 중요하기 때문. 이 Contract들의 역할과 구성을 알아보면, 좀 더 구체적으로 Layer2가 어떻게 작동하는지 이해할 수 있기 때문에 한번 정리해보려 한다. (코드는 파헤치는건 다음에...) 배포되는 컨트랙트..