일반적인 오라클의 동작방식은
sm-stack · 2025.10.16 · Short
일반적인 오라클의 동작방식은 1. 오라클 네트워크가 오프체인에서 합의 2. 트랜잭션을 보내 컨트랙트를 업데이트 와 같았습니다. 다시 얘기하자면, 오라클 네트워크가 컨트랙트에 트랜잭션을 보내는 주기보다 더 빠르게 정보 업데이트를 받아볼 수 없었죠. 이번 체인링크와의 협업을 통해 이를 프리컴파일로 지원하게 되면, 실시간으로 DON이 합의한 데이터를 컨트랙트
일반적인 오라클의 동작방식은 1. 오라클 네트워크가 오프체인에서 합의 2. 트랜잭션을 보내 컨트랙트를 업데이트 와 같았습니다. 다시 얘기하자면, 오라클 네트워크가 컨트랙트에 트랜잭션을 보내는 주기보다 더 빠르게 정보 업데이트를 받아볼 수 없었죠. 이번 체인링크와의 협업을 통해 이를 프리컴파일로 지원하게 되면, 실시간으로 DON이 합의한 데이터를 컨트랙트에서 받아볼 수 있게 됩니다. 정보가 더 정확해질 뿐만 아니라, 그 정보를 가지고 컨트랙트 내에서 composable한 액션들을 더 빠르게 수행해볼 수 있겠죠. 개발자 및 사용자 경험에 큰 이점이 될 것으로 생각됩니다. 다만 엔지니어링 관점에서 중요해보이는 두 가지 포인트는 1. 10ms 수준의 빠른 사전확인을 추구하는 메가이더에서, 프리컴파일을 통한 오라클 호출이 병목이 되지 않는 저지연 아키텍처 설계 2. 결국 EVM을 수정하는 행위니, 증명 시스템이 체인링크 오라클 프리컴파일을 통합해야 하는데 그 방식이 어떠할지 특히 2번의 경우 메가이더는 ZK 사기 증명을 사용할텐데, 특정 블록에 대해 챌린지가 제기되었을 때 그 블록에 포함된 오라클 호출의 결과를 어떻게 검증하고 신뢰할 것인지가 중요한 문제로 보입니다. 해결하기 매우 까다로워 보이고, 잘못 핸들링하면 시퀀서가 오라클 호출의 결과를 조작하는 공격 시나리오도 가능할 것 같은데, 실제 메가이더의 구현이 어떻게 될지 궁금하네요!