Subscribe to stalim17
![Cover image for Announcing OPCraft: an Autonomous World built on the OP Stack-OP LABS BLOG [KOR]](https://img.paragraph.com/cdn-cgi/image/format=auto,width=3840,quality=85/https://storage.googleapis.com/papyrus_images/8dbf7fba6a3ff8d5451be5f6c2247468b5345e954ccf943532145bc133681890.png)
stalim17Announcing OPCraft: an Autonomous World built on the OP Stack-OP LABS BLOG [KOR]
비밀스러운 작은 세계…지난 몇 달 동안 Lattice는 Optimism 팀과 흥미로운 기술 협력을 진행했습니다. Twitter에서 이를 엿볼 수 있습니다. 자율 세계를 언급하는 이모티콘 벽이 있는 트윗이나 고르지 않은 풍경의 전경에 있는 재미있어 보이는 구조의 스크린샷입니다. 또는 흥미로운 새 온체인 게임에 대한 이야기를 Devcon에 있었던 친구들로부터 우연히 들었을 수도 있습니다. 오늘 우리는 OP Stack (Optimism의 모듈식 롤업 아키텍처) 위에 MUD (오픈 소스 온체인 게임 엔진) 로 구축된 완전한 온체인 3D 복셀 세계인 OPCraft를 공식적으로 공개합니다 .그렇다면 OPCraft는 무엇입니까?OPCraft는 Autonomous World입니다. 세계의 모든 단일 측면(모든 강, 풀잎, 산맥 꼭대기에 있는 눈 조각)이 온체인에 존재하는 완전한 온체인 가상 공간과 세계의 모든 단일 작업입니다. Ethereum 트랜잭션으로 발생합니다. 다른 제작 기반 복셀 세...
![Cover image for A Summer of Optimism [KOR]](https://img.paragraph.com/cdn-cgi/image/format=auto,width=3840,quality=85/https://storage.googleapis.com/papyrus_images/b9dab26b6790e5cf020436e92255802b3f2fb2d8ae29de5adc0ce7948bc90d1d.jpg)
stalim17A Summer of Optimism [KOR]
이후 기대감이 고조되고 있습니다 . 발표된 지난 주 Optimism Collective가 OP 여름이 될 것입니다. 앞으로 몇 주 동안 우리는 Optimism Collective의 지속 가능한 미래를 어떻게 확장할 계획인지에 대한 자세한 내용을 게시할 예정입니다. 오늘부터 OP Stimpack을 시작으로 합니다. Token House의 첫 번째 공식 조치인 이를 통해 거버넌스 펀드(231,928,234 OP)가 활성화되어 OP 메인넷의 성장에 대한 인센티브가 시작됩니다. 통해 규모에 맞는 지속 가능한 거버넌스를 위한 당사의 장기 비전에 대해 읽어보실 수 있습니다 소급 공공재 자금 지원을 에서 OP 경제학 개요 . 단기적으로는 토큰 공급량(231,928,234 OP)의 5.4%가 거버넌스 펀드를 통해 기존 및 신규 OP 메인넷 프로젝트에 분배될 예정입니다. 우리는 이 새로운 디지털 개척지의 기반을 구축하고 있지만 이를 현실로 가져오는 사람은 프로젝트와 사용자인 여러분입니다 .0에...
stalim17Dope Hires & Moar Mainnet in March [KOR]
이것은 우리가 팀에 만든 놀라운 추가 사항을 발표하기 위해 오랫동안 기한이 지난 게시물입니다. 우리는 11월에 Paradigm의 낙관적인 공급을 풍부하게 재확보한 a16z가 주도한 펀딩 라운드를 마감했습니다 . 이 현금을 통해 우리는 공간에서 가장 명석한 마음과 날카로운 운영자와 함께 빠르게 확장할 수 있었습니다. 이런 인재를 채용할 수 있게 되어서 3월에 퍼블릭 테스트넷이 아닌 메인넷에 임의 계약 배포를 시작 합니다!! 자세한 내용은 곧 제공됩니다. 우리는 지금 채용 중 입니다 . 아래 사람들과 같은 사람이라면 채용하고 싶습니다 .마크 타인웨이(영어)Mark는 Bitcoin에 대해 배우고 그것에 대해 더 배우기 위해 모든 것을 포기해야 할 때까지 신경 과학자로서 학문적 경력을 추구했습니다. 그는 bcoin이라는 비트코인의 대체 구현에 기여했으며 Handshake 출시를 도왔고 Optimism에 합류하여 Ethereum 확장 작업을 수행했습니다. “ 블록체인은 조정 문제를 ...
<100 subscribers
Support stalim17
stalim17The Highly Optimistic Dev Blog #01: The Mystery of the Missing Message[KOR]
편집팀의 메모:
옵티미스틱 이더리움 의 우주에는 흥미로운 작업이 너무 많아서 우리가 무엇을 했는지 세상에 알리기 위해 잠시 시간을 내는 것을 종종 잊습니다. 낙관적 이더리움의 내부 작동 방식과 이를 실현하는 데 도움을 주는 사람들에 대해 더 자세히 알고 싶다는 많은 분들의 의견을 들었습니다. 그 결과 우리는 낙관적 이더리움에서 일하는 사람들이 매일 그들이 다루는 아이디어와 도전에 대해 글을 쓰는 데브 블로그를 시작합니다 . 우리는 이러한 블로그 게시물에 특정 스타일이나 구조를 적용하지 않습니다. 우리 각자가 Optimism에서 우리의 작업에 대해 생각하는 방식을 그대로 볼 수 있습니다. 우리는 이것이 낙관적 경험을 들여다보는 작은 창처럼 작용하기를 바랍니다.
Highly Optimistic Dev Blog의 첫 번째 버전에 오신 것을 환영합니다! ☺️
저자: 켈빈 피처
이것은 2021년 6월 초 며칠 동안 Optimistic Ethereum 테스트넷 배포가 새로운 L1 ⇒ L2 예금 수락을 중단 하게 만든 버그를 조사한 경험에 대한 이야기입니다 . 어떤 맥락에서 L1 ⇒ L2 예금은 자산을 가져갑니다. L1 체인(Ethereum과 같은)에 앉아 L2 체인(Optimistic Ethereum과 같은)으로 이동합니다. 사건이 발생하는 동안 테스트넷 배포는 예치금을 올바르게 신용할 수 없었습니다. 버그의 정확한 원인을 이해하지 않고도 문제에 대한 합리적인 수정을 만들 수 있었기 때문에 이 이야기가 매력적이라는 것을 알았습니다 . 인간을 위한 소프트웨어 구축의 지저분한 현실을 강조하는 이야기 중 하나입니다. 나는 또한 이 게시물에 우리가 사고에서 얻은 엔지니어링 교훈 중 일부를 흩뿌릴 것입니다. 즐기다!
여러 사용자가 직접 문제를 보고한 후 Kovan 예금 문제를 처음 알게 되었습니다(이러한 종류의 문제에 대한 자동 경고를 개선해야 함을 상기). 보고된 일반적인 증상은 사용자가 L1에서 거래를 전송하여 입금을 시작할 수 있었지만 L2에서는 자금을 받지 못했다는 것입니다. 분명히 이것은 사용자가 자산을 L2로 이동하는 것을 막았기 때문에 꽤 문제가 있었습니다. 이것은 확실히 가능한 한 빨리 수정되어야 했습니다.
엔지니어링 수업 #1: 사용자 신고는 최후의 방어선입니다.
사용자 보고서는 문제를 발견할 때 최후의 방어선이 되어야 합니다. 사용자 보고서로 인해 문제를 발견한 경우 적절한 알림이 충분하지 않을 수 있습니다. 이 특정한 경우에 우리는 정기적으로 예금 트랜잭션을 제출하고 해당 트랜잭션의 실패를 모니터링해야 했습니다.
잠재적으로 문제를 일으킬 수 있는 소프트웨어의 여러 부분에 대한 작은 목록을 작성하여 디버깅 세션을 시작했습니다. 사용자 보고서를 기반으로 우리는 다음을 알고 있었습니다.
예금은 L1에서 올바르게 시작될 수 있습니다.
입금액이 L2에 올바르게 반영되지 않았습니다.
포인트 (1)은 스마트 계약에서 버그가 발생 하지 않았을 가능성이 있음 을 의미합니다 (예금 거래가 스마트 계약에서 문제인 경우 되돌릴 수 있음). 다행스럽게도 우리의 소프트웨어 스택은 상대적으로 단순하고 버그가 숨길 곳이 많지 않습니다. 문제가 계약에 없는 경우 L2 geth 노드에 있거나 L2 geth( 데이터 전송 계층 또는 DTL 이라고 하는 도구)로 트랜잭션을 전달하는 프로세스에 있었습니다 . 대안에 대한 제안을 받고 있습니다 😂).
DTL은 이와 같은 오류가 자주 발생하지 않는 최소한의 소프트웨어입니다. 우리는 우리 자신의 예금을 몇 개 만들었고 DTL이 이러한 예금을 올바르게 발견하고 인덱싱하고 있음을 발견했기 때문에 우리의 의심은 L2 geth로 바뀌었습니다 . 로그를 빠르게 훑어봐도 우리의 새로운 예금 거래가 분명히 L2에서 실행되고 있지 않다는 사실 외에는 많은 것이 드러나지 않았습니다.
다행히 다음 로그 라인을 발견했을 때 운이 좋았습니다.
대기열에 넣기 트랜잭션 동기화 범위 시작=2500 end=3545
...
대기열에 넣기 트랜잭션 동기화 범위 시작=2500 end=3546
...
대기열에 넣기 트랜잭션 동기화 범위 시작=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>
우리는 무엇을 되찾았습니까? null. 분명히 DTL은 이 입금에 대한 기록이 없었습니다.
그럼 보증금은 2501?
GET <https://url.of.dtl/enqueue/index/2501>
아니 null! 예, DTL에는 이에 대한 기록이 있습니다. 그리고 그 이후에 다른 모든 예금에 대한 기록이 있었습니다. 이것은 분명히 초기 문제의 원인이었습니다. DTL에는 입금 내역이 없어서 2500L2 geth는 입금 이상으로 진행하지 못했으나 2500신규 입금이 계속 접수되고 있었습니다. 흠...
이 버그의 기이한 특성은 비결정론적일 수 있음을 시사했습니다. 내 말은, 왜 보증금 이 2500누락되었을까요? 아니나 다를까 처음부터 동기화된 새 DTL이 예치금을 제대로 가져왔습니다. 즉, 프로덕션 DTL을 재설정하여 시스템을 다시 온라인 상태로 만들 수 있었지만 처음에 왜 이런 일이 발생했는지 정확히 이해하지 못했습니다. 앞으로 유사한 문제가 발생하지 않도록 근본 원인을 찾기 시작했습니다.
운이 좋게도 DTL은 비교적 단순한 소프트웨어입니다. 많은 일을 하지 않습니다. 기본적으로 다음과 같은 루프입니다.
결과적으로 이렇게 깨질 수 있는 것은 많지 않습니다. 우리에게 눈에 띄는 것이 없었기 때문에 우리는 결국 약간의 파기를 해야 했습니다. 가능성을 낮추기 위해 세 가지 잠재적인 버그 원인을 생각해 냈습니다.
첫 번째 직감은 Kovan이 대규모 블록 재구성을 경험했을 수도 있다는 것입니다. 대규모 재구성이 발생하면 노드는 일시적으로 네트워크의 오래된 보기를 볼 수 있습니다. Kovan의 DTL 은 트랜잭션을 수락하기 전에 12개의 확인(블록)을 기다리도록 구성되었습니다 . 이것이 근본 원인이라면 12개 이상의 블록에 대한 일종의 재구성이 예상됩니다.
Etherscan의 reorg 목록을 간단히 살펴보고 원점으로 돌아왔습니다. 사건 당시 거의 한 달 동안 개편이 없었습니다. Etherscan이 대규모 국지적 중단을 경험하고 Kovan의 나머지 부분과 동기화되지 않는 한, 눈에 띄지 않는 12개 이상의 블록 재구성이 있었을 가능성은 없습니다. 다음으로 넘어갑니다.
재구성이 아니었다면 우리 소프트웨어가 동기화 프로세스 중에 실수로 블록을 건너뛴 것일 수 있습니다. 그럴 가능성은 거의 없어 보였지만 이것이 문제의 원인이 아닌지 확인해야 했습니다.
우리가 블록을 건너뛰었는지 여부를 알아내기 위해 예치금이 포함된 L1 블록을 스캔했는지 알려주는 특정 로그 라인을 찾아야 했습니다 . 그러기 위해서는 먼저 이벤트가 발생한 블록을 찾아야 했습니다. 그래서 보증금을 찾기 위해 Etherscan으로 돌아 갔습니다 .
여기서 반환 값은 다음 형식의 구조체입니다.
여기서 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을 재동기화하여 시스템을 백업할 수 있다는 것을 알고 있었지만 근본 원인 없이는 아마도 하루나 이틀 후에 같은 문제에 직면하게 될 것입니다.
약간의 논의 끝에 다음과 같은 절충안이 도출되었습니다.
DTL을 다시 동기화하여 시스템을 백업하십시오.
이 복구 논리가 트리거될 때마다 로그 줄을 추가하여 나중에 추가로 디버깅할 수 있습니다.
이 전략은 상황을 최대한 활용했습니다. DTL의 새로운 복구 논리는 근본적인 문제의 최악의 영향으로부터 우리를 보호했습니다. 버그가 다시 고개를 들면 정지된 시스템 대신 편리한 로그 라인을 얻게 됩니다. 윈윈.
공학 수업 #4: 근본 원인이 전부는 아닙니다.
문제를 완전히 이해하기 전에 문제를 완화하는 것이 가능하거나 더 나은 경우도 있습니다. 문제의 향후 발생을 계속 모니터링해야 합니다. 알 수 없는 버그가 시스템에서 유발할 수 있는 다른 효과를 브레인스토밍하는 것을 고려하십시오.
그리고 근본 원인을 이해하지 않고도 버그를 효과적으로 완화할 수 있었습니다. 패치는 원래 사건 이후 여러 차례 이 오류를 성공적으로 복구했습니다. 이 게시물을 작성하는 시점에서 우리는 아직 이 문제의 근본 원인을 파악하지 못했습니다. 작업할 다른 작업이 너무 많고 그동안 복구 논리가 이 문제를 완벽하게 잘 처리하고 있습니다. , 결함 허용!).
나는 이 사가가 소프트웨어 엔지니어링의 더 더러운 측면을 강조했기 때문에 매우 흥미로웠다. 소프트웨어를 구축하고 유지 관리하는 프로세스는 우리 모두가 원하는 것처럼 간단하지 않습니다. 실용적인 문제는 종종 "이상적인" 방법을 희생하면서 올 수 있습니다. 결국 좋은 소프트웨어 엔지니어링은 순수 수학이라기보다는 대략적인 과학에 가깝습니다. 사람들이 다른 사람들을 위해 소프트웨어를 만들 때 발생하는 지저분한 상황을 처리해야 합니다 . 당신이 할 수 있는 일은 최선을 다하는 것입니다. 배우고, 적응하고, 계속 나아가십시오.
우리는 Ethereum의 미래를 구축하기 위해 고용하고 있습니다. 여기에서 읽은 내용이 마음에 들면 채용 공고를 확인하십시오 . 다음 집을 찾을 수도 있습니다. 💖
편집팀의 메모:
옵티미스틱 이더리움 의 우주에는 흥미로운 작업이 너무 많아서 우리가 무엇을 했는지 세상에 알리기 위해 잠시 시간을 내는 것을 종종 잊습니다. 낙관적 이더리움의 내부 작동 방식과 이를 실현하는 데 도움을 주는 사람들에 대해 더 자세히 알고 싶다는 많은 분들의 의견을 들었습니다. 그 결과 우리는 낙관적 이더리움에서 일하는 사람들이 매일 그들이 다루는 아이디어와 도전에 대해 글을 쓰는 데브 블로그를 시작합니다 . 우리는 이러한 블로그 게시물에 특정 스타일이나 구조를 적용하지 않습니다. 우리 각자가 Optimism에서 우리의 작업에 대해 생각하는 방식을 그대로 볼 수 있습니다. 우리는 이것이 낙관적 경험을 들여다보는 작은 창처럼 작용하기를 바랍니다.
Highly Optimistic Dev Blog의 첫 번째 버전에 오신 것을 환영합니다! ☺️
저자: 켈빈 피처
이것은 2021년 6월 초 며칠 동안 Optimistic Ethereum 테스트넷 배포가 새로운 L1 ⇒ L2 예금 수락을 중단 하게 만든 버그를 조사한 경험에 대한 이야기입니다 . 어떤 맥락에서 L1 ⇒ L2 예금은 자산을 가져갑니다. L1 체인(Ethereum과 같은)에 앉아 L2 체인(Optimistic Ethereum과 같은)으로 이동합니다. 사건이 발생하는 동안 테스트넷 배포는 예치금을 올바르게 신용할 수 없었습니다. 버그의 정확한 원인을 이해하지 않고도 문제에 대한 합리적인 수정을 만들 수 있었기 때문에 이 이야기가 매력적이라는 것을 알았습니다 . 인간을 위한 소프트웨어 구축의 지저분한 현실을 강조하는 이야기 중 하나입니다. 나는 또한 이 게시물에 우리가 사고에서 얻은 엔지니어링 교훈 중 일부를 흩뿌릴 것입니다. 즐기다!
여러 사용자가 직접 문제를 보고한 후 Kovan 예금 문제를 처음 알게 되었습니다(이러한 종류의 문제에 대한 자동 경고를 개선해야 함을 상기). 보고된 일반적인 증상은 사용자가 L1에서 거래를 전송하여 입금을 시작할 수 있었지만 L2에서는 자금을 받지 못했다는 것입니다. 분명히 이것은 사용자가 자산을 L2로 이동하는 것을 막았기 때문에 꽤 문제가 있었습니다. 이것은 확실히 가능한 한 빨리 수정되어야 했습니다.
엔지니어링 수업 #1: 사용자 신고는 최후의 방어선입니다.
사용자 보고서는 문제를 발견할 때 최후의 방어선이 되어야 합니다. 사용자 보고서로 인해 문제를 발견한 경우 적절한 알림이 충분하지 않을 수 있습니다. 이 특정한 경우에 우리는 정기적으로 예금 트랜잭션을 제출하고 해당 트랜잭션의 실패를 모니터링해야 했습니다.
잠재적으로 문제를 일으킬 수 있는 소프트웨어의 여러 부분에 대한 작은 목록을 작성하여 디버깅 세션을 시작했습니다. 사용자 보고서를 기반으로 우리는 다음을 알고 있었습니다.
예금은 L1에서 올바르게 시작될 수 있습니다.
입금액이 L2에 올바르게 반영되지 않았습니다.
포인트 (1)은 스마트 계약에서 버그가 발생 하지 않았을 가능성이 있음 을 의미합니다 (예금 거래가 스마트 계약에서 문제인 경우 되돌릴 수 있음). 다행스럽게도 우리의 소프트웨어 스택은 상대적으로 단순하고 버그가 숨길 곳이 많지 않습니다. 문제가 계약에 없는 경우 L2 geth 노드에 있거나 L2 geth( 데이터 전송 계층 또는 DTL 이라고 하는 도구)로 트랜잭션을 전달하는 프로세스에 있었습니다 . 대안에 대한 제안을 받고 있습니다 😂).
DTL은 이와 같은 오류가 자주 발생하지 않는 최소한의 소프트웨어입니다. 우리는 우리 자신의 예금을 몇 개 만들었고 DTL이 이러한 예금을 올바르게 발견하고 인덱싱하고 있음을 발견했기 때문에 우리의 의심은 L2 geth로 바뀌었습니다 . 로그를 빠르게 훑어봐도 우리의 새로운 예금 거래가 분명히 L2에서 실행되고 있지 않다는 사실 외에는 많은 것이 드러나지 않았습니다.
다행히 다음 로그 라인을 발견했을 때 운이 좋았습니다.
대기열에 넣기 트랜잭션 동기화 범위 시작=2500 end=3545
...
대기열에 넣기 트랜잭션 동기화 범위 시작=2500 end=3546
...
대기열에 넣기 트랜잭션 동기화 범위 시작=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>
우리는 무엇을 되찾았습니까? null. 분명히 DTL은 이 입금에 대한 기록이 없었습니다.
그럼 보증금은 2501?
GET <https://url.of.dtl/enqueue/index/2501>
아니 null! 예, DTL에는 이에 대한 기록이 있습니다. 그리고 그 이후에 다른 모든 예금에 대한 기록이 있었습니다. 이것은 분명히 초기 문제의 원인이었습니다. DTL에는 입금 내역이 없어서 2500L2 geth는 입금 이상으로 진행하지 못했으나 2500신규 입금이 계속 접수되고 있었습니다. 흠...
이 버그의 기이한 특성은 비결정론적일 수 있음을 시사했습니다. 내 말은, 왜 보증금 이 2500누락되었을까요? 아니나 다를까 처음부터 동기화된 새 DTL이 예치금을 제대로 가져왔습니다. 즉, 프로덕션 DTL을 재설정하여 시스템을 다시 온라인 상태로 만들 수 있었지만 처음에 왜 이런 일이 발생했는지 정확히 이해하지 못했습니다. 앞으로 유사한 문제가 발생하지 않도록 근본 원인을 찾기 시작했습니다.
운이 좋게도 DTL은 비교적 단순한 소프트웨어입니다. 많은 일을 하지 않습니다. 기본적으로 다음과 같은 루프입니다.
결과적으로 이렇게 깨질 수 있는 것은 많지 않습니다. 우리에게 눈에 띄는 것이 없었기 때문에 우리는 결국 약간의 파기를 해야 했습니다. 가능성을 낮추기 위해 세 가지 잠재적인 버그 원인을 생각해 냈습니다.
첫 번째 직감은 Kovan이 대규모 블록 재구성을 경험했을 수도 있다는 것입니다. 대규모 재구성이 발생하면 노드는 일시적으로 네트워크의 오래된 보기를 볼 수 있습니다. Kovan의 DTL 은 트랜잭션을 수락하기 전에 12개의 확인(블록)을 기다리도록 구성되었습니다 . 이것이 근본 원인이라면 12개 이상의 블록에 대한 일종의 재구성이 예상됩니다.
Etherscan의 reorg 목록을 간단히 살펴보고 원점으로 돌아왔습니다. 사건 당시 거의 한 달 동안 개편이 없었습니다. Etherscan이 대규모 국지적 중단을 경험하고 Kovan의 나머지 부분과 동기화되지 않는 한, 눈에 띄지 않는 12개 이상의 블록 재구성이 있었을 가능성은 없습니다. 다음으로 넘어갑니다.
재구성이 아니었다면 우리 소프트웨어가 동기화 프로세스 중에 실수로 블록을 건너뛴 것일 수 있습니다. 그럴 가능성은 거의 없어 보였지만 이것이 문제의 원인이 아닌지 확인해야 했습니다.
우리가 블록을 건너뛰었는지 여부를 알아내기 위해 예치금이 포함된 L1 블록을 스캔했는지 알려주는 특정 로그 라인을 찾아야 했습니다 . 그러기 위해서는 먼저 이벤트가 발생한 블록을 찾아야 했습니다. 그래서 보증금을 찾기 위해 Etherscan으로 돌아 갔습니다 .
여기서 반환 값은 다음 형식의 구조체입니다.
여기서 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을 재동기화하여 시스템을 백업할 수 있다는 것을 알고 있었지만 근본 원인 없이는 아마도 하루나 이틀 후에 같은 문제에 직면하게 될 것입니다.
약간의 논의 끝에 다음과 같은 절충안이 도출되었습니다.
DTL을 다시 동기화하여 시스템을 백업하십시오.
이 복구 논리가 트리거될 때마다 로그 줄을 추가하여 나중에 추가로 디버깅할 수 있습니다.
이 전략은 상황을 최대한 활용했습니다. DTL의 새로운 복구 논리는 근본적인 문제의 최악의 영향으로부터 우리를 보호했습니다. 버그가 다시 고개를 들면 정지된 시스템 대신 편리한 로그 라인을 얻게 됩니다. 윈윈.
공학 수업 #4: 근본 원인이 전부는 아닙니다.
문제를 완전히 이해하기 전에 문제를 완화하는 것이 가능하거나 더 나은 경우도 있습니다. 문제의 향후 발생을 계속 모니터링해야 합니다. 알 수 없는 버그가 시스템에서 유발할 수 있는 다른 효과를 브레인스토밍하는 것을 고려하십시오.
그리고 근본 원인을 이해하지 않고도 버그를 효과적으로 완화할 수 있었습니다. 패치는 원래 사건 이후 여러 차례 이 오류를 성공적으로 복구했습니다. 이 게시물을 작성하는 시점에서 우리는 아직 이 문제의 근본 원인을 파악하지 못했습니다. 작업할 다른 작업이 너무 많고 그동안 복구 논리가 이 문제를 완벽하게 잘 처리하고 있습니다. , 결함 허용!).
나는 이 사가가 소프트웨어 엔지니어링의 더 더러운 측면을 강조했기 때문에 매우 흥미로웠다. 소프트웨어를 구축하고 유지 관리하는 프로세스는 우리 모두가 원하는 것처럼 간단하지 않습니다. 실용적인 문제는 종종 "이상적인" 방법을 희생하면서 올 수 있습니다. 결국 좋은 소프트웨어 엔지니어링은 순수 수학이라기보다는 대략적인 과학에 가깝습니다. 사람들이 다른 사람들을 위해 소프트웨어를 만들 때 발생하는 지저분한 상황을 처리해야 합니다 . 당신이 할 수 있는 일은 최선을 다하는 것입니다. 배우고, 적응하고, 계속 나아가십시오.
우리는 Ethereum의 미래를 구축하기 위해 고용하고 있습니다. 여기에서 읽은 내용이 마음에 들면 채용 공고를 확인하십시오 . 다음 집을 찾을 수도 있습니다. 💖
stalim17Announcing OPCraft: an Autonomous World built on the OP Stack-OP LABS BLOG [KOR]
비밀스러운 작은 세계…지난 몇 달 동안 Lattice는 Optimism 팀과 흥미로운 기술 협력을 진행했습니다. Twitter에서 이를 엿볼 수 있습니다. 자율 세계를 언급하는 이모티콘 벽이 있는 트윗이나 고르지 않은 풍경의 전경에 있는 재미있어 보이는 구조의 스크린샷입니다. 또는 흥미로운 새 온체인 게임에 대한 이야기를 Devcon에 있었던 친구들로부터 우연히 들었을 수도 있습니다. 오늘 우리는 OP Stack (Optimism의 모듈식 롤업 아키텍처) 위에 MUD (오픈 소스 온체인 게임 엔진) 로 구축된 완전한 온체인 3D 복셀 세계인 OPCraft를 공식적으로 공개합니다 .그렇다면 OPCraft는 무엇입니까?OPCraft는 Autonomous World입니다. 세계의 모든 단일 측면(모든 강, 풀잎, 산맥 꼭대기에 있는 눈 조각)이 온체인에 존재하는 완전한 온체인 가상 공간과 세계의 모든 단일 작업입니다. Ethereum 트랜잭션으로 발생합니다. 다른 제작 기반 복셀 세...
stalim17A Summer of Optimism [KOR]
이후 기대감이 고조되고 있습니다 . 발표된 지난 주 Optimism Collective가 OP 여름이 될 것입니다. 앞으로 몇 주 동안 우리는 Optimism Collective의 지속 가능한 미래를 어떻게 확장할 계획인지에 대한 자세한 내용을 게시할 예정입니다. 오늘부터 OP Stimpack을 시작으로 합니다. Token House의 첫 번째 공식 조치인 이를 통해 거버넌스 펀드(231,928,234 OP)가 활성화되어 OP 메인넷의 성장에 대한 인센티브가 시작됩니다. 통해 규모에 맞는 지속 가능한 거버넌스를 위한 당사의 장기 비전에 대해 읽어보실 수 있습니다 소급 공공재 자금 지원을 에서 OP 경제학 개요 . 단기적으로는 토큰 공급량(231,928,234 OP)의 5.4%가 거버넌스 펀드를 통해 기존 및 신규 OP 메인넷 프로젝트에 분배될 예정입니다. 우리는 이 새로운 디지털 개척지의 기반을 구축하고 있지만 이를 현실로 가져오는 사람은 프로젝트와 사용자인 여러분입니다 .0에...
stalim17Dope Hires & Moar Mainnet in March [KOR]
이것은 우리가 팀에 만든 놀라운 추가 사항을 발표하기 위해 오랫동안 기한이 지난 게시물입니다. 우리는 11월에 Paradigm의 낙관적인 공급을 풍부하게 재확보한 a16z가 주도한 펀딩 라운드를 마감했습니다 . 이 현금을 통해 우리는 공간에서 가장 명석한 마음과 날카로운 운영자와 함께 빠르게 확장할 수 있었습니다. 이런 인재를 채용할 수 있게 되어서 3월에 퍼블릭 테스트넷이 아닌 메인넷에 임의 계약 배포를 시작 합니다!! 자세한 내용은 곧 제공됩니다. 우리는 지금 채용 중 입니다 . 아래 사람들과 같은 사람이라면 채용하고 싶습니다 .마크 타인웨이(영어)Mark는 Bitcoin에 대해 배우고 그것에 대해 더 배우기 위해 모든 것을 포기해야 할 때까지 신경 과학자로서 학문적 경력을 추구했습니다. 그는 bcoin이라는 비트코인의 대체 구현에 기여했으며 Handshake 출시를 도왔고 Optimism에 합류하여 Ethereum 확장 작업을 수행했습니다. “ 블록체인은 조정 문제를 ...
Share Dialog
Share Dialog
No comments yet