stalim17Arbitrary Token Bridging
TL; DR오늘 우리는 Optimistic Ethereum에 대한 임의의 토큰 입금 및 인출을 가능하게 하는 새로운 게이트웨이 인터페이스를 출시하게 되어 매우 기쁩니다! 게이트웨이의 이전 주요 릴리스에서는 Optimism 토큰 목록 에 나열된 토큰을 L2로(및 그 반대로) 전송하도록 허용했습니다. 이 새로운 릴리스를 통해 우리는 혁신의 문을 열고 모든 ERC20 토큰이 계층 간의 경계를 전환할 수 있도록 하고자 합니다.작동 원리L2 체인을 개발할 때 토큰 브리징을 처리하는 방법을 알아내는 것은 복잡하고 균형이 풍부한 환경을 만듭니다. 우리의 브리지 구현은 다음과 같은 사실 간의 균형을 제공하고자 합니다.ERC20은 인터페이스일 뿐입니다 . L1에는 수백 가지의 다양한 토큰 구현이 있습니다. 이들 중 일부는 즉시 사용 가능한 OpenZeppelin 토큰과 크게 다릅니다. 따라서 모든 잠재적 유형의 예금 자금을 포괄하는 단일 "브리지 ERC20" 구현을 안치하는 것은 불가능합니다....
stalim17The Highly Optimistic Dev Blog #01: The Mystery of the Missing Message[KOR]
편집팀의 메모: 옵티미스틱 이더리움 의 우주에는 흥미로운 작업이 너무 많아서 우리가 무엇을 했는지 세상에 알리기 위해 잠시 시간을 내는 것을 종종 잊습니다. 낙관적 이더리움의 내부 작동 방식과 이를 실현하는 데 도움을 주는 사람들에 대해 더 자세히 알고 싶다는 많은 분들의 의견을 들었습니다. 그 결과 우리는 낙관적 이더리움에서 일하는 사람들이 매일 그들이 다루는 아이디어와 도전에 대해 글을 쓰는 데브 블로그를 시작합니다 . 우리는 이러한 블로그 게시물에 특정 스타일이나 구조를 적용하지 않습니다. 우리 각자가 Optimism에서 우리의 작업에 대해 생각하는 방식을 그대로 볼 수 있습니다. 우리는 이것이 낙관적 경험을 들여다보는 작은 창처럼 작용하기를 바랍니다. Highly Optimistic Dev Blog의 첫 번째 버전에 오신 것을 환영합니다! ☺️ 저자: 켈빈 피처요약 및 배경이것은 2021년 6월 초 며칠 동안 Optimistic Ethereum 테스트넷 배포가 새로운 L...
![Cover image for OVM Deep Dive [KOR]](https://img.paragraph.com/cdn-cgi/image/format=auto,width=3840,quality=85/https://storage.googleapis.com/papyrus_images/7bed0c28a7451bc3ac2d6c15ff32525701f35fb9e1f206452879effbef6ace46.png)
stalim17OVM Deep Dive [KOR]
핵심요약 – Layer 2 시스템용으로 설계된 모든 기능을 갖춘 EVM 호환 실행 환경인 OVM을 구축했습니다. 이 게시물은 OVM이 이더리움 메인 체인과 동일한 롤업을 가능하게 하는 방법을 설명합니다. OVM을 구축하는 이유는 무엇입니까? 우리 팀의 많은 사람들은 이전에 계약을 지원하는 최초의 일반화된 플라즈마 구성인 plapps를 설계하기 위해 일했습니다 ! 그러나 plapps에는 제한된 "단어" 계약과 관련된 완전히 새로운 개발자 도구가 필요했습니다. 이더리움 L2는 단순히 이더리움을 사용하여 확장하는 것을 의미하는 것이 아니라 이더리움 자체를 확장하는 것을 의미합니다 . 이것은 결국 이더리움 스마트 계약의 전체 기능 세트를 확장성 환경으로 가져오겠다고 약속한 최초의 L2 구성인 Optimistic Rollup을 개발하게 했습니다 . Unipig.exchange는 처음으로 이 전례 없는 기능을 시연했습니다. 처음으로 Uniswap은 L2에 있었습니다. 그러나 Unipig는...
www.twitter.com/stalim1717
Support stalim17
![Reliability and Hardening-OP LABS BLOG [KOR]](https://img.paragraph.com/cdn-cgi/image/format=auto,width=3840,quality=85/https://storage.googleapis.com/papyrus_images/f5c87f17c99e400535826a8b7ba189b144b2b38ec7a545d98ab909d9592de97b.png)
stalim17Reliability and Hardening-OP LABS BLOG [KOR]
Support stalim17
stalim17Reliability and Hardening-OP LABS BLOG [KOR]
stalim17Arbitrary Token Bridging
TL; DR오늘 우리는 Optimistic Ethereum에 대한 임의의 토큰 입금 및 인출을 가능하게 하는 새로운 게이트웨이 인터페이스를 출시하게 되어 매우 기쁩니다! 게이트웨이의 이전 주요 릴리스에서는 Optimism 토큰 목록 에 나열된 토큰을 L2로(및 그 반대로) 전송하도록 허용했습니다. 이 새로운 릴리스를 통해 우리는 혁신의 문을 열고 모든 ERC20 토큰이 계층 간의 경계를 전환할 수 있도록 하고자 합니다.작동 원리L2 체인을 개발할 때 토큰 브리징을 처리하는 방법을 알아내는 것은 복잡하고 균형이 풍부한 환경을 만듭니다. 우리의 브리지 구현은 다음과 같은 사실 간의 균형을 제공하고자 합니다.ERC20은 인터페이스일 뿐입니다 . L1에는 수백 가지의 다양한 토큰 구현이 있습니다. 이들 중 일부는 즉시 사용 가능한 OpenZeppelin 토큰과 크게 다릅니다. 따라서 모든 잠재적 유형의 예금 자금을 포괄하는 단일 "브리지 ERC20" 구현을 안치하는 것은 불가능합니다....
stalim17The Highly Optimistic Dev Blog #01: The Mystery of the Missing Message[KOR]
편집팀의 메모: 옵티미스틱 이더리움 의 우주에는 흥미로운 작업이 너무 많아서 우리가 무엇을 했는지 세상에 알리기 위해 잠시 시간을 내는 것을 종종 잊습니다. 낙관적 이더리움의 내부 작동 방식과 이를 실현하는 데 도움을 주는 사람들에 대해 더 자세히 알고 싶다는 많은 분들의 의견을 들었습니다. 그 결과 우리는 낙관적 이더리움에서 일하는 사람들이 매일 그들이 다루는 아이디어와 도전에 대해 글을 쓰는 데브 블로그를 시작합니다 . 우리는 이러한 블로그 게시물에 특정 스타일이나 구조를 적용하지 않습니다. 우리 각자가 Optimism에서 우리의 작업에 대해 생각하는 방식을 그대로 볼 수 있습니다. 우리는 이것이 낙관적 경험을 들여다보는 작은 창처럼 작용하기를 바랍니다. Highly Optimistic Dev Blog의 첫 번째 버전에 오신 것을 환영합니다! ☺️ 저자: 켈빈 피처요약 및 배경이것은 2021년 6월 초 며칠 동안 Optimistic Ethereum 테스트넷 배포가 새로운 L...
stalim17OVM Deep Dive [KOR]
핵심요약 – Layer 2 시스템용으로 설계된 모든 기능을 갖춘 EVM 호환 실행 환경인 OVM을 구축했습니다. 이 게시물은 OVM이 이더리움 메인 체인과 동일한 롤업을 가능하게 하는 방법을 설명합니다. OVM을 구축하는 이유는 무엇입니까? 우리 팀의 많은 사람들은 이전에 계약을 지원하는 최초의 일반화된 플라즈마 구성인 plapps를 설계하기 위해 일했습니다 ! 그러나 plapps에는 제한된 "단어" 계약과 관련된 완전히 새로운 개발자 도구가 필요했습니다. 이더리움 L2는 단순히 이더리움을 사용하여 확장하는 것을 의미하는 것이 아니라 이더리움 자체를 확장하는 것을 의미합니다 . 이것은 결국 이더리움 스마트 계약의 전체 기능 세트를 확장성 환경으로 가져오겠다고 약속한 최초의 L2 구성인 Optimistic Rollup을 개발하게 했습니다 . Unipig.exchange는 처음으로 이 전례 없는 기능을 시연했습니다. 처음으로 Uniswap은 L2에 있었습니다. 그러나 Unipig는...
www.twitter.com/stalim1717
Subscribe to stalim17
Subscribe to stalim17
<100 subscribers
<100 subscribers
처음에 mainnet.optimism.io는 도메인 별칭에 불과했습니다. 모든 실제 인프라는 QuickNode에서 처리했습니다. 이를 통해 사용자가 네트워크에 액세스하는 방법에 대한 걱정 없이 핵심 프로토콜 개발에 집중할 수 있습니다. 우리는 성장하면서 단순한 도메인 별칭이 제공할 수 있는 것 이상의 것이 필요하다는 것을 깨달았습니다.
자체 메트릭을 생성하고 이를 경고할 수 있는 기능이 필요했습니다.
어떤 사용자 RPC가 실패했고 그 이유가 무엇인지 정확히 진단하려면 자세한 로그가 필요했습니다.
시퀀서를 보호하기 위해 특정 RPC를 화이트리스트에 추가하는 기능이 필요했습니다.
QuickNode에 다운타임이 발생한 경우 자동으로 다른 제공업체로 장애 조치하는 방법이 필요했습니다.
퍼블릭 엔드포인트 호스팅 비용을 줄이고 싶었습니다.
또한 반목표도 있었습니다. 스스로 인프라 공급자가 되지 말라는 것입니다. 퍼블릭 엔드포인트는 매일 약 1억 건의 요청을 봅니다. 많은 요청을 처리하는 것은 어렵고 노드 인프라 실행은 우리의 핵심 비즈니스가 아닙니다. 따라서 퍼블릭 노드를 직접 운영하지 않고도 위의 문제를 해결할 필요가 있었습니다.
우리의 솔루션은 모든 RPC 트래픽을 proxyd. proxyd개별 RPC를 업스트림 인프라 공급자 그룹(구성에서 "백엔드"라고 함)으로 라우팅할 수 있습니다. 그룹의 백엔드 중 하나가 실패하면 proxyd구성 가능한 기간 동안 자동으로 서비스 중단으로 표시하고 다른 공급자로 장애 조치합니다. proxyd또한 RPC 메서드 캐싱을 지원하고 RPC 사용을 분석하기 위해 풍부한 Prometheus 메트릭 세트를 노출합니다.
다음과 같은 TOML 파일을 사용하여 구성됩니다.
[backends] response_timeout_seconds = 5 max_retries = 3 out_of_service_seconds = 30
[backends.infura] rpc_url = "..." ws_url = "..."
[backends.alchemy] rpc_url = "..." ws_url = "..."
[backend_groups] [backend_groups.providers] backends = ["alchemy","infura"]
# Mapping of methods to backend groups. [rpc_method_mappings] eth_getBalance = "providers" 여기서 eth_getBalance호출은 Alchemy로 라우팅됩니다. Alchemy가 실패하면 호출이 30초 동안 Infura로 라우팅됩니다. 그 후 proxyd연금술을 다시 시도합니다.
처음에 mainnet.optimism.io는 도메인 별칭에 불과했습니다. 모든 실제 인프라는 QuickNode에서 처리했습니다. 이를 통해 사용자가 네트워크에 액세스하는 방법에 대한 걱정 없이 핵심 프로토콜 개발에 집중할 수 있습니다. 우리는 성장하면서 단순한 도메인 별칭이 제공할 수 있는 것 이상의 것이 필요하다는 것을 깨달았습니다.
자체 메트릭을 생성하고 이를 경고할 수 있는 기능이 필요했습니다.
어떤 사용자 RPC가 실패했고 그 이유가 무엇인지 정확히 진단하려면 자세한 로그가 필요했습니다.
시퀀서를 보호하기 위해 특정 RPC를 화이트리스트에 추가하는 기능이 필요했습니다.
QuickNode에 다운타임이 발생한 경우 자동으로 다른 제공업체로 장애 조치하는 방법이 필요했습니다.
퍼블릭 엔드포인트 호스팅 비용을 줄이고 싶었습니다.
또한 반목표도 있었습니다. 스스로 인프라 공급자가 되지 말라는 것입니다. 퍼블릭 엔드포인트는 매일 약 1억 건의 요청을 봅니다. 많은 요청을 처리하는 것은 어렵고 노드 인프라 실행은 우리의 핵심 비즈니스가 아닙니다. 따라서 퍼블릭 노드를 직접 운영하지 않고도 위의 문제를 해결할 필요가 있었습니다.
우리의 솔루션은 모든 RPC 트래픽을 proxyd. proxyd개별 RPC를 업스트림 인프라 공급자 그룹(구성에서 "백엔드"라고 함)으로 라우팅할 수 있습니다. 그룹의 백엔드 중 하나가 실패하면 proxyd구성 가능한 기간 동안 자동으로 서비스 중단으로 표시하고 다른 공급자로 장애 조치합니다. proxyd또한 RPC 메서드 캐싱을 지원하고 RPC 사용을 분석하기 위해 풍부한 Prometheus 메트릭 세트를 노출합니다.
다음과 같은 TOML 파일을 사용하여 구성됩니다.
[backends] response_timeout_seconds = 5 max_retries = 3 out_of_service_seconds = 30
[backends.infura] rpc_url = "..." ws_url = "..."
[backends.alchemy] rpc_url = "..." ws_url = "..."
[backend_groups] [backend_groups.providers] backends = ["alchemy","infura"]
# Mapping of methods to backend groups. [rpc_method_mappings] eth_getBalance = "providers" 여기서 eth_getBalance호출은 Alchemy로 라우팅됩니다. Alchemy가 실패하면 호출이 30초 동안 Infura로 라우팅됩니다. 그 후 proxyd연금술을 다시 시도합니다.
Kovan을 메인넷에 배포하기 전에 대략 한 달 동안 Kovan을 테스트했습니다 proxyd. 그 과정에서 우리가 배운 가장 흥미로운 것들 중 일부는 다음과 같습니다.
인프라 공급자는 Geth의 표준 RPC 구현에서 벗어난 미묘하고 종종 문서화되지 않은 한계를 가지고 있습니다. 이러한 제한에 도달하면 사용자에게 직접 반환되며 어떤 종류의 경고도 트리거하지 않습니다. 결과적으로 메트릭은 요청된 RPC 메서드뿐만 아니라 업스트림 공급자가 반환한 원시 오류 코드도 추적해야 했습니다. WebSockets 또는 RPC 일괄 처리를 사용하는 애플리케이션은 거의 없습니다. 대부분의 HTTP 요청에는 단일 RPC 호출이 포함됩니다. 이것은 속도 제한을 설계하는 동안 중요한 요소였습니다. dApp을 통한 단일 브라우저 세션 클릭이 분당 수천 건의 HTTP 요청을 시작할 수 있기 때문입니다. 업스트림 오류는 생각보다 많이 발생합니다. 일반적으로 2-3초 내에 해결되지만 그럼에도 불구하고 오류입니다. 결과적으로 proxyd이러한 문제를 사용자에게 숨기기 위해 내부적으로 업스트림 공급자를 다시 시도합니다. 한 번에 3개 제공자에게 데이터를 요청하고 제공자의 2/3가 동의한 데이터를 반환하는 실험을 실행했습니다. 이러지 마. 공급자가 단일 블록에 대한 합의에 도달하는 데 약 10-15초가 걸리며 사용자가 기다리기에는 너무 깁니다. 가장 많이 요청된 RPC 호출 중 일부는 간단하게 캐시할 수 있습니다. eth_chainId우리의 경우 하루에 수백만 번 호출되는 와 같은 것입니다 . 이와 같은 캐싱 방법은 인프라 비용을 매월 수백 달러 절약할 수 있습니다.
💡 그건 그렇고, 프록시는 오픈 소스입니다! https://github.com/ethereum-optimism/optimism/tree/develop/go/proxyd 에서 찾을 수 있습니다 . 퍼블릭 엔드포인트를 실행 중이거나 중복 인프라 공급자에 액세스하는 방법을 원하는 경우 확인하십시오.
파트 3: 결과
현재 우리 proxyd클러스터는 메인넷에 있으며 하루에 약 1억 건의 요청을 처리합니다. 그렇다면 이것이 사용자에게 의미하는 바는 무엇입니까? 그 뜻은:
이 모든 작업의 주요 목표는 가동 시간을 개선하는 것입니다. 퍼블릭 엔드포인트가 다운되면 시퀀서가 아무 작업도 수행하지 않는데도 Optimism 자체가 다운된 것처럼 느껴집니다. 이 작업을 올바르게 수행하면 이러한 변경 사항이 완전히 투명해야 합니다.
이전에는 문제의 전제 조건에 대한 통찰력이 없었습니다. 예를 들어 사용자가 문제를 보고하기 시작한 후에야 Lyra 토큰 출시에 영향을 미치는 문제를 알게 되었습니다. 이상 현상이 발생하면 문제가 발생하기 전에 모니터링할 수 있도록 대기 중인 엔지니어에게 ping을 보내는 모니터링 및 경고가 준비되어 있습니다.
예를 들어, 다음은 사용자가 공급자별 제한(이 경우 eth_getLog요청에 대한 QuickNode의 최대 10,000개 블록)에 직면한 최근에 우리가 경험한 이상 현상입니다.
최선을 다해도 문제가 계속 발생할 수 있습니다. 이런 일이 발생하면 사용자 문제를 가능한 한 빨리 진단할 수 있는 것이 중요합니다. 이것은 모든 RPC 요청에 대한 자세한 오류 정보를 볼 수 있는 능력이 없었기 때문에 어려운 pre-`proxyd`였습니다. 이제 아래와 같은 대시보드가 생겼습니다. 이 대시보드는 사용자가 RPC 및 공급자별로 경험하고 있는 오류 코드를 정확히 보여줍니다.
그런 다음 로깅 도구인 StackDriver로 이동하여 각 오류의 근본 원인을 정확히 확인할 수 있습니다.
이렇게 하면 문제가 발생한 이유에 대한 데이터 수집 프로세스를 단축하고 문제를 더 빨리 해결할 수 있습니다.
Kovan을 메인넷에 배포하기 전에 대략 한 달 동안 Kovan을 테스트했습니다 proxyd. 그 과정에서 우리가 배운 가장 흥미로운 것들 중 일부는 다음과 같습니다.
인프라 공급자는 Geth의 표준 RPC 구현에서 벗어난 미묘하고 종종 문서화되지 않은 한계를 가지고 있습니다. 이러한 제한에 도달하면 사용자에게 직접 반환되며 어떤 종류의 경고도 트리거하지 않습니다. 결과적으로 메트릭은 요청된 RPC 메서드뿐만 아니라 업스트림 공급자가 반환한 원시 오류 코드도 추적해야 했습니다. WebSockets 또는 RPC 일괄 처리를 사용하는 애플리케이션은 거의 없습니다. 대부분의 HTTP 요청에는 단일 RPC 호출이 포함됩니다. 이것은 속도 제한을 설계하는 동안 중요한 요소였습니다. dApp을 통한 단일 브라우저 세션 클릭이 분당 수천 건의 HTTP 요청을 시작할 수 있기 때문입니다. 업스트림 오류는 생각보다 많이 발생합니다. 일반적으로 2-3초 내에 해결되지만 그럼에도 불구하고 오류입니다. 결과적으로 proxyd이러한 문제를 사용자에게 숨기기 위해 내부적으로 업스트림 공급자를 다시 시도합니다. 한 번에 3개 제공자에게 데이터를 요청하고 제공자의 2/3가 동의한 데이터를 반환하는 실험을 실행했습니다. 이러지 마. 공급자가 단일 블록에 대한 합의에 도달하는 데 약 10-15초가 걸리며 사용자가 기다리기에는 너무 깁니다. 가장 많이 요청된 RPC 호출 중 일부는 간단하게 캐시할 수 있습니다. eth_chainId우리의 경우 하루에 수백만 번 호출되는 와 같은 것입니다 . 이와 같은 캐싱 방법은 인프라 비용을 매월 수백 달러 절약할 수 있습니다.
💡 그건 그렇고, 프록시는 오픈 소스입니다! https://github.com/ethereum-optimism/optimism/tree/develop/go/proxyd 에서 찾을 수 있습니다 . 퍼블릭 엔드포인트를 실행 중이거나 중복 인프라 공급자에 액세스하는 방법을 원하는 경우 확인하십시오.
파트 3: 결과
현재 우리 proxyd클러스터는 메인넷에 있으며 하루에 약 1억 건의 요청을 처리합니다. 그렇다면 이것이 사용자에게 의미하는 바는 무엇입니까? 그 뜻은:
이 모든 작업의 주요 목표는 가동 시간을 개선하는 것입니다. 퍼블릭 엔드포인트가 다운되면 시퀀서가 아무 작업도 수행하지 않는데도 Optimism 자체가 다운된 것처럼 느껴집니다. 이 작업을 올바르게 수행하면 이러한 변경 사항이 완전히 투명해야 합니다.
이전에는 문제의 전제 조건에 대한 통찰력이 없었습니다. 예를 들어 사용자가 문제를 보고하기 시작한 후에야 Lyra 토큰 출시에 영향을 미치는 문제를 알게 되었습니다. 이상 현상이 발생하면 문제가 발생하기 전에 모니터링할 수 있도록 대기 중인 엔지니어에게 ping을 보내는 모니터링 및 경고가 준비되어 있습니다.
예를 들어, 다음은 사용자가 공급자별 제한(이 경우 eth_getLog요청에 대한 QuickNode의 최대 10,000개 블록)에 직면한 최근에 우리가 경험한 이상 현상입니다.
최선을 다해도 문제가 계속 발생할 수 있습니다. 이런 일이 발생하면 사용자 문제를 가능한 한 빨리 진단할 수 있는 것이 중요합니다. 이것은 모든 RPC 요청에 대한 자세한 오류 정보를 볼 수 있는 능력이 없었기 때문에 어려운 pre-`proxyd`였습니다. 이제 아래와 같은 대시보드가 생겼습니다. 이 대시보드는 사용자가 RPC 및 공급자별로 경험하고 있는 오류 코드를 정확히 보여줍니다.
그런 다음 로깅 도구인 StackDriver로 이동하여 각 오류의 근본 원인을 정확히 확인할 수 있습니다.
이렇게 하면 문제가 발생한 이유에 대한 데이터 수집 프로세스를 단축하고 문제를 더 빨리 해결할 수 있습니다.
Share Dialog
Share Dialog
No activity yet