이것은 2021년 6월 초 며칠 동안 Optimistic Ethereum 테스트넷 배포가 새로운 L1 ⇒ L2 예금 수락을 중단 하게 만든 버그를 조사한 경험에 대한 이야기입니다 . 어떤 맥락에서 L1 ⇒ L2 예금은 자산을 가져갑니다. L1 체인(Ethereum과 같은)에 앉아 L2 체인(Optimistic Ethereum과 같은)으로 이동합니다. 사건이 발생하는 동안 테스트넷 배포는 예치금을 올바르게 신용할 수 없었습니다. 버그의 정확한 원인을 이해하지 않고도 문제에 대한 합리적인 수정을 만들 수 있었기 때문에 이 이야기가 매력적이라는 것을 알았습니다 . 인간을 위한 소프트웨어 구축의 지저분한 현실을 강조하는 이야기 중 하나입니다. 나는 또한 이 게시물에 우리가 사고에서 얻은 엔지니어링 교훈 중 일부를 흩뿌릴 것입니다. 즐기다!

여러 사용자가 직접 문제를 보고한 후 Kovan 예금 문제를 처음 알게 되었습니다(이러한 종류의 문제에 대한 자동 경고를 개선해야 함을 상기). 보고된 일반적인 증상은 사용자가 L1에서 거래를 전송하여 입금을 시작할 수 있었지만 L2에서는 자금을 받지 못했다는 것입니다. 분명히 이것은 사용자가 자산을 L2로 이동하는 것을 막았기 때문에 꽤 문제가 있었습니다. 이것은 확실히 가능한 한 빨리 수정되어야 했습니다.

엔지니어링 수업 #1: 사용자 보고서는 최후의 방어선입니다.*

사용자 보고서는 문제를 발견할 때 최후의 방어선이어야 합니다. 사용자 보고서로 인해 문제를 발견한 경우 적절한 알림이 충분하지 않을 수 있습니다. 이 특정한 경우에 우리는 정기적으로 예금 트랜잭션을 제출하고 해당 트랜잭션의 실패를 모니터링해야 했습니다.*

잠재적으로 문제를 일으킬 수 있는 소프트웨어의 여러 부분에 대한 작은 목록을 작성하여 디버깅 세션을 시작했습니다. 사용자 보고서를 기반으로 우리는 다음을 알고 있었습니다.

1. 예금은 L1에서 올바르게 시작될 수 있습니다.

2. 입금액이 L2에 올바르게 반영되지 않았습니다.

포인트 (1)은 스마트 계약에서 버그가 발생 하지 않았을 가능성이 있음 을 의미합니다 (예금 거래가 스마트 계약에서 문제인 경우 되돌릴 수 있음). 다행스럽게도 우리의 소프트웨어 스택은 상대적으로 단순하고 버그가 숨길 곳이 많지 않습니다. 문제가 계약에 없는 경우 L2 geth 노드에 있거나 L2 geth( 데이터 전송 계층 또는 DTL 이라고 하는 도구)로 트랜잭션을 전달하는 프로세스에 있었습니다 . 대안에 대한 제안을 받고 있습니다 😂).

DTL은 이와 같은 오류가 자주 발생하지 않는 최소한의 소프트웨어입니다. 우리는 우리 자신의 예금을 몇 개 만들었고 DTL이 이러한 예금을 올바르게 발견하고 인덱싱하고 있음을 발견했기 때문에 우리의 의심은 L2 geth로 바뀌었습니다 . 로그를 빠르게 훑어봐도 우리의 새로운 예금 거래가 분명히 L2에서 실행되고 있지 않다는 사실 외에는 많은 것이 드러나지 않았습니다.

다행히 다음 로그 라인을 발견했을 때 운이 좋았습니다.

Syncing enqueue transactions range start=2500 end=3545 ... Syncing enqueue transactions range start=2500 end=3546 ... Syncing enqueue transactions range start=2500 end=3547

이러한 로그는 L2 geth가 일련의 L1 ⇒ L2 예금 트랜잭션을 실행하려고 할 때 생성됩니다 . startL2 geth가 하나의 트랜잭션을 실행하고 다음 트랜잭션으로 이동해야 하기 때문에 시간이 지남에 따라 값이 증가할 것으로 예상됩니다 . 값이 변경되지 않는다는 사실은 startdeposit 을 실행하려고 할 때 L2 geth가 어떻게든 멈춘다는 것을 암시했습니다 2500. 이제 우리는 예금에 무슨 일이 일어나고 있는지 알아내야 했습니다 2500.

무슨 일이 일어나고 있는지 파악하는 가장 쉬운 방법은 데이터 전송 계층을 확인하여 무엇이 L2 geth로 전송되고 있는지 확인하는 것이었습니다. DTL에는 시퀀서로 전송되는 내용을 확인하기 위해 수동으로 쿼리할 수 있는 멋진 API가 있습니다. 그래서 다음 쿼리를 보냈습니다.

GET <https://url.of.dtl/enqueue/index/2500>

우리는 무엇을 되찾았습니까? 없는. 분명히 DTL은 이 입금에 대한 기록이 없었습니다.

예금 2501은 어떻습니까?

GET <https://url.of.dtl/enqueue/index/2501>

아니 null! 예, DTL에는 이에 대한 기록이 있습니다. 그리고 그 이후에 다른 모든 예금에 대한 기록이 있었습니다. 이것은 분명히 초기 문제의 원인이었습니다. DTL에는 입금 내역이 없어서 2500L2 geth는 입금 이상으로 진행하지 못했으나 2500신규 입금이 계속 접수되고 있었습니다. 흠...

이 버그의 기이한 특성은 비결정론적일 수 있음을 시사했습니다. 내 말은, 왜 보증금 이 2500누락되었을까요? 아니나 다를까 처음부터 동기화된 새 DTL이 예치금을 제대로 가져왔습니다. 즉, 프로덕션 DTL을 재설정하여 시스템을 다시 온라인 상태로 만들 수 있었지만 처음에 왜 이런 일이 발생했는지 정확히 이해하지 못했습니다. 앞으로 유사한 문제가 발생하지 않도록 근본 원인을 찾기 시작했습니다.

운이 좋게도 DTL은 비교적 단순한 소프트웨어입니다. 많은 일을 하지 않습니다. 기본적으로 다음과 같은 루프입니다.

1. 동기화된 마지막 L1 블록을 찾습니다.

2. 동기화할 다음 L1 블록을 찾습니다.

3. 해당 블록 범위 내에서 이벤트를 찾고 구문 분석하고 저장합니다.

4. 동기화된 마지막 L1 블록을 업데이트합니다.

결과적으로 이렇게 깨질 수 있는 것은 많지 않습니다. 우리에게 눈에 띄는 것이 없었기 때문에 우리는 결국 약간의 파기를 해야 했습니다. 가능성을 낮추기 위해 세 가지 잠재적인 버그 원인을 생각해 냈습니다.

첫 번째 직감은 Kovan이 대규모 블록 재구성을 경험했을 수도 있다는 것입니다. 대규모 재구성이 발생하면 노드는 일시적으로 네트워크의 오래된 보기를 볼 수 있습니다. Kovan의 DTL 은 트랜잭션을 수락하기 전에 12개의 확인(블록)을 기다리도록 구성되었습니다 . 이것이 근본 원인이라면 12개 이상의 블록에 대한 일종의 재구성이 예상됩니다.

Etherscan의 reorg 목록을 간단히 살펴보고 원점으로 돌아왔습니다. 사건 당시 거의 한 달 동안 개편이 없었습니다. Etherscan이 대규모 국지적 중단을 경험하고 Kovan의 나머지 부분과 동기화되지 않는 한, 눈에 띄지 않는 12개 이상의 블록 재구성이 있었을 가능성은 없습니다. 다음으로 넘어갑니다.

재구성이 아니었다면 우리 소프트웨어가 동기화 프로세스 중에 실수로 블록을 건너뛴 것일 수 있습니다. 그럴 가능성은 거의 없어 보였지만 이것이 문제의 원인이 아닌지 확인해야 했습니다.

우리가 블록을 건너뛰었는지 여부를 알아내기 위해 예치금이 포함된 L1 블록을 스캔했는지 알려주는 특정 로그 라인을 찾아야 했습니다 . 그러기 위해서는 먼저 이벤트가 발생한 블록을 찾아야 했습니다. 그래서 보증금을 찾기 위해 Etherscan으로 돌아 갔습니다 .

여기서 반환 값은 다음 형식의 구조체입니다.

struct QueueElement {      bytes32 transactionHash;      uint40 timestamp;      uint40 blockNumber; }

여기서 timestamp및 blockNumberhere는 이 예치금이 제출된 블록의 타임스탬프와 블록 번호입니다. 우리는 우리가 원하는 것을 가지고 있었습니다: 이 예치금은 블록에 제출되었습니다 25371197. 이제 문제의 블록을 포함하는 로그를 찾기 위해 DTL 로그를 살펴보기만 하면 되었습니다. 확실히:

이 로그 라인의 는 targetL1Block우리가 찾고 있던 L1 블록과 일치합니다. 보증금이 포함된 블록을 확실히 동기화하려고 시도했습니다 . 그래서 우리는 왜 아무것도 보지 못했습니까?

DTL 로그를 조사한 결과 입금이 DTL에서 감지되어야 했지만 감지되지 않았음이 분명해졌습니다. 또한 DTL은 이 블록을 동기화할 때 오류를 발생시키지 않았습니다. 이벤트를 찾지 못했습니다 .

DTL 코드에 비교적 자신이 있었기 때문에 우리는 우리 자신이 아닌 다른 사람을 비난할 잠재적인 이유를 찾기 시작했습니다(그렇게 하는 것이 더 쉽기 때문입니다). Infura가 이 오류가 발생했을 때 거의 동시에 다양한 504 오류를 반환하고 있음을 발견했습니다.

흥미로운? 예. Infura에 문제가 있다는 증거? 그다지. 6월 9일 Infura에서 문제가 발생했을 수 있습니다. 아니면 아닐 수도 있습니다. 누가 알아. 안타깝게도 RPC 요청 기록을 저장하지 않았기 때문에 로그만으로는 이 문제를 더 이상 디버깅할 수 없었습니다.

엔지니어링 수업 #2: RPC 요청을 기록해 두십시오.*

Ethereum 노드가 시스템에 중요한 경우 노드에 대한 모든 RPC 요청의 기록을 유지하는 것이 좋습니다. 스토리지 비용을 낮게 유지하기 위해 일정 기간이 지나면 로그를 항상 삭제할 수 있습니다.*

공학 수업 #3: Infura는 합의가 아닙니다.*

들어오는 결과의 유효성을 교차 확인하기 위해 동시에 여러 노드 또는 노드 공급자에게 요청을 보내는 것을 고려하십시오 . 이러한 노드 중 하나 이상을 직접 호스팅하는 것을 고려하십시오. 노드 공급자가 항상 올바른 결과를 반환한다는 가정에 절대 의존해서는 안 됩니다. 신뢰하되 확인하십시오.*

우리는 Infura가 고장났거나 우리 시스템에 우리가 알아낼 수 없는 버그가 있었다는 상대적으로 만족스럽지 못한 결론에 갇혔습니다. 우리는 또한 사람들이 Kovan 테스트넷에 의존하고 시스템에 대한 입금이 여전히 완전히 중단되었기 때문에 약간의 압력을 받았습니다. 우리는 DTL을 재동기화하여 시스템을 백업할 수 있다는 것을 알고 있었지만 근본 원인 없이는 아마도 하루나 이틀 후에 같은 문제에 직면하게 될 것입니다.

약간의 논의 끝에 다음과 같은 절충안이 도출되었습니다.

1. DTL을 다시 동기화하여 시스템을 백업하십시오.

2. 누락된 이벤트를 복구할 수 있도록 DTL에 논리를 추가하십시오 .

3. 이 복구 논리가 트리거될 때마다 로그 줄을 추가하여 나중에 추가로 디버깅할 수 있습니다.

이 전략은 상황을 최대한 활용했습니다. DTL의 새로운 복구 논리는 근본적인 문제의 최악의 영향으로부터 우리를 보호했습니다. 버그가 다시 고개를 들면 정지된 시스템 대신 편리한 로그 라인을 얻게 됩니다. 윈윈.

이것은 2021년 6월 초 며칠 동안 Optimistic Ethereum 테스트넷 배포가 새로운 L1 ⇒ L2 예금 수락을 중단 하게 만든 버그를 조사한 경험에 대한 이야기입니다 . 어떤 맥락에서 L1 ⇒ L2 예금은 자산을 가져갑니다. L1 체인(Ethereum과 같은)에 앉아 L2 체인(Optimistic Ethereum과 같은)으로 이동합니다. 사건이 발생하는 동안 테스트넷 배포는 예치금을 올바르게 신용할 수 없었습니다. 버그의 정확한 원인을 이해하지 않고도 문제에 대한 합리적인 수정을 만들 수 있었기 때문에 이 이야기가 매력적이라는 것을 알았습니다 . 인간을 위한 소프트웨어 구축의 지저분한 현실을 강조하는 이야기 중 하나입니다. 나는 또한 이 게시물에 우리가 사고에서 얻은 엔지니어링 교훈 중 일부를 흩뿌릴 것입니다. 즐기다!

여러 사용자가 직접 문제를 보고한 후 Kovan 예금 문제를 처음 알게 되었습니다(이러한 종류의 문제에 대한 자동 경고를 개선해야 함을 상기). 보고된 일반적인 증상은 사용자가 L1에서 거래를 전송하여 입금을 시작할 수 있었지만 L2에서는 자금을 받지 못했다는 것입니다. 분명히 이것은 사용자가 자산을 L2로 이동하는 것을 막았기 때문에 꽤 문제가 있었습니다. 이것은 확실히 가능한 한 빨리 수정되어야 했습니다.

엔지니어링 수업 #1: 사용자 보고서는 최후의 방어선입니다.*

사용자 보고서는 문제를 발견할 때 최후의 방어선이어야 합니다. 사용자 보고서로 인해 문제를 발견한 경우 적절한 알림이 충분하지 않을 수 있습니다. 이 특정한 경우에 우리는 정기적으로 예금 트랜잭션을 제출하고 해당 트랜잭션의 실패를 모니터링해야 했습니다.*

잠재적으로 문제를 일으킬 수 있는 소프트웨어의 여러 부분에 대한 작은 목록을 작성하여 디버깅 세션을 시작했습니다. 사용자 보고서를 기반으로 우리는 다음을 알고 있었습니다.

1. 예금은 L1에서 올바르게 시작될 수 있습니다.

2. 입금액이 L2에 올바르게 반영되지 않았습니다.

포인트 (1)은 스마트 계약에서 버그가 발생 하지 않았을 가능성이 있음 을 의미합니다 (예금 거래가 스마트 계약에서 문제인 경우 되돌릴 수 있음). 다행스럽게도 우리의 소프트웨어 스택은 상대적으로 단순하고 버그가 숨길 곳이 많지 않습니다. 문제가 계약에 없는 경우 L2 geth 노드에 있거나 L2 geth( 데이터 전송 계층 또는 DTL 이라고 하는 도구)로 트랜잭션을 전달하는 프로세스에 있었습니다 . 대안에 대한 제안을 받고 있습니다 😂).

DTL은 이와 같은 오류가 자주 발생하지 않는 최소한의 소프트웨어입니다. 우리는 우리 자신의 예금을 몇 개 만들었고 DTL이 이러한 예금을 올바르게 발견하고 인덱싱하고 있음을 발견했기 때문에 우리의 의심은 L2 geth로 바뀌었습니다 . 로그를 빠르게 훑어봐도 우리의 새로운 예금 거래가 분명히 L2에서 실행되고 있지 않다는 사실 외에는 많은 것이 드러나지 않았습니다.

다행히 다음 로그 라인을 발견했을 때 운이 좋았습니다.

Syncing enqueue transactions range start=2500 end=3545 ... Syncing enqueue transactions range start=2500 end=3546 ... Syncing enqueue transactions range start=2500 end=3547

이러한 로그는 L2 geth가 일련의 L1 ⇒ L2 예금 트랜잭션을 실행하려고 할 때 생성됩니다 . startL2 geth가 하나의 트랜잭션을 실행하고 다음 트랜잭션으로 이동해야 하기 때문에 시간이 지남에 따라 값이 증가할 것으로 예상됩니다 . 값이 변경되지 않는다는 사실은 startdeposit 을 실행하려고 할 때 L2 geth가 어떻게든 멈춘다는 것을 암시했습니다 2500. 이제 우리는 예금에 무슨 일이 일어나고 있는지 알아내야 했습니다 2500.

무슨 일이 일어나고 있는지 파악하는 가장 쉬운 방법은 데이터 전송 계층을 확인하여 무엇이 L2 geth로 전송되고 있는지 확인하는 것이었습니다. DTL에는 시퀀서로 전송되는 내용을 확인하기 위해 수동으로 쿼리할 수 있는 멋진 API가 있습니다. 그래서 다음 쿼리를 보냈습니다.

GET <https://url.of.dtl/enqueue/index/2500>

우리는 무엇을 되찾았습니까? 없는. 분명히 DTL은 이 입금에 대한 기록이 없었습니다.

예금 2501은 어떻습니까?

GET <https://url.of.dtl/enqueue/index/2501>

아니 null! 예, DTL에는 이에 대한 기록이 있습니다. 그리고 그 이후에 다른 모든 예금에 대한 기록이 있었습니다. 이것은 분명히 초기 문제의 원인이었습니다. DTL에는 입금 내역이 없어서 2500L2 geth는 입금 이상으로 진행하지 못했으나 2500신규 입금이 계속 접수되고 있었습니다. 흠...

이 버그의 기이한 특성은 비결정론적일 수 있음을 시사했습니다. 내 말은, 왜 보증금 이 2500누락되었을까요? 아니나 다를까 처음부터 동기화된 새 DTL이 예치금을 제대로 가져왔습니다. 즉, 프로덕션 DTL을 재설정하여 시스템을 다시 온라인 상태로 만들 수 있었지만 처음에 왜 이런 일이 발생했는지 정확히 이해하지 못했습니다. 앞으로 유사한 문제가 발생하지 않도록 근본 원인을 찾기 시작했습니다.

운이 좋게도 DTL은 비교적 단순한 소프트웨어입니다. 많은 일을 하지 않습니다. 기본적으로 다음과 같은 루프입니다.

1. 동기화된 마지막 L1 블록을 찾습니다.

2. 동기화할 다음 L1 블록을 찾습니다.

3. 해당 블록 범위 내에서 이벤트를 찾고 구문 분석하고 저장합니다.

4. 동기화된 마지막 L1 블록을 업데이트합니다.

결과적으로 이렇게 깨질 수 있는 것은 많지 않습니다. 우리에게 눈에 띄는 것이 없었기 때문에 우리는 결국 약간의 파기를 해야 했습니다. 가능성을 낮추기 위해 세 가지 잠재적인 버그 원인을 생각해 냈습니다.

첫 번째 직감은 Kovan이 대규모 블록 재구성을 경험했을 수도 있다는 것입니다. 대규모 재구성이 발생하면 노드는 일시적으로 네트워크의 오래된 보기를 볼 수 있습니다. Kovan의 DTL 은 트랜잭션을 수락하기 전에 12개의 확인(블록)을 기다리도록 구성되었습니다 . 이것이 근본 원인이라면 12개 이상의 블록에 대한 일종의 재구성이 예상됩니다.

Etherscan의 reorg 목록을 간단히 살펴보고 원점으로 돌아왔습니다. 사건 당시 거의 한 달 동안 개편이 없었습니다. Etherscan이 대규모 국지적 중단을 경험하고 Kovan의 나머지 부분과 동기화되지 않는 한, 눈에 띄지 않는 12개 이상의 블록 재구성이 있었을 가능성은 없습니다. 다음으로 넘어갑니다.

재구성이 아니었다면 우리 소프트웨어가 동기화 프로세스 중에 실수로 블록을 건너뛴 것일 수 있습니다. 그럴 가능성은 거의 없어 보였지만 이것이 문제의 원인이 아닌지 확인해야 했습니다.

우리가 블록을 건너뛰었는지 여부를 알아내기 위해 예치금이 포함된 L1 블록을 스캔했는지 알려주는 특정 로그 라인을 찾아야 했습니다 . 그러기 위해서는 먼저 이벤트가 발생한 블록을 찾아야 했습니다. 그래서 보증금을 찾기 위해 Etherscan으로 돌아 갔습니다 .

여기서 반환 값은 다음 형식의 구조체입니다.

struct QueueElement {      bytes32 transactionHash;      uint40 timestamp;      uint40 blockNumber; }

여기서 timestamp및 blockNumberhere는 이 예치금이 제출된 블록의 타임스탬프와 블록 번호입니다. 우리는 우리가 원하는 것을 가지고 있었습니다: 이 예치금은 블록에 제출되었습니다 25371197. 이제 문제의 블록을 포함하는 로그를 찾기 위해 DTL 로그를 살펴보기만 하면 되었습니다. 확실히:

이 로그 라인의 는 targetL1Block우리가 찾고 있던 L1 블록과 일치합니다. 보증금이 포함된 블록을 확실히 동기화하려고 시도했습니다 . 그래서 우리는 왜 아무것도 보지 못했습니까?

DTL 로그를 조사한 결과 입금이 DTL에서 감지되어야 했지만 감지되지 않았음이 분명해졌습니다. 또한 DTL은 이 블록을 동기화할 때 오류를 발생시키지 않았습니다. 이벤트를 찾지 못했습니다 .

DTL 코드에 비교적 자신이 있었기 때문에 우리는 우리 자신이 아닌 다른 사람을 비난할 잠재적인 이유를 찾기 시작했습니다(그렇게 하는 것이 더 쉽기 때문입니다). Infura가 이 오류가 발생했을 때 거의 동시에 다양한 504 오류를 반환하고 있음을 발견했습니다.

흥미로운? 예. Infura에 문제가 있다는 증거? 그다지. 6월 9일 Infura에서 문제가 발생했을 수 있습니다. 아니면 아닐 수도 있습니다. 누가 알아. 안타깝게도 RPC 요청 기록을 저장하지 않았기 때문에 로그만으로는 이 문제를 더 이상 디버깅할 수 없었습니다.

엔지니어링 수업 #2: RPC 요청을 기록해 두십시오.*

Ethereum 노드가 시스템에 중요한 경우 노드에 대한 모든 RPC 요청의 기록을 유지하는 것이 좋습니다. 스토리지 비용을 낮게 유지하기 위해 일정 기간이 지나면 로그를 항상 삭제할 수 있습니다.*

공학 수업 #3: Infura는 합의가 아닙니다.*

들어오는 결과의 유효성을 교차 확인하기 위해 동시에 여러 노드 또는 노드 공급자에게 요청을 보내는 것을 고려하십시오 . 이러한 노드 중 하나 이상을 직접 호스팅하는 것을 고려하십시오. 노드 공급자가 항상 올바른 결과를 반환한다는 가정에 절대 의존해서는 안 됩니다. 신뢰하되 확인하십시오.*

우리는 Infura가 고장났거나 우리 시스템에 우리가 알아낼 수 없는 버그가 있었다는 상대적으로 만족스럽지 못한 결론에 갇혔습니다. 우리는 또한 사람들이 Kovan 테스트넷에 의존하고 시스템에 대한 입금이 여전히 완전히 중단되었기 때문에 약간의 압력을 받았습니다. 우리는 DTL을 재동기화하여 시스템을 백업할 수 있다는 것을 알고 있었지만 근본 원인 없이는 아마도 하루나 이틀 후에 같은 문제에 직면하게 될 것입니다.

약간의 논의 끝에 다음과 같은 절충안이 도출되었습니다.

1. DTL을 다시 동기화하여 시스템을 백업하십시오.

2. 누락된 이벤트를 복구할 수 있도록 DTL에 논리를 추가하십시오 .

3. 이 복구 논리가 트리거될 때마다 로그 줄을 추가하여 나중에 추가로 디버깅할 수 있습니다.

이 전략은 상황을 최대한 활용했습니다. DTL의 새로운 복구 논리는 근본적인 문제의 최악의 영향으로부터 우리를 보호했습니다. 버그가 다시 고개를 들면 정지된 시스템 대신 편리한 로그 라인을 얻게 됩니다. 윈윈.