.png)
Arcium은 MXE를 사용하는 암호화 명령어의 지연 시간을 대폭 줄여주는 공유 비밀번호 캐싱 최적화 기술을 선보입니다. 기존에는 모든 암호화 명령어마다 MPC 환경에서 디피-헬만(Diffie-Hellman) 방식으로 도출된 공유 비밀번호를 재계산해야 했기 때문에, 요청당 약 1초의 오버헤드가 발생했습니다. 새로운 설계는 공유 비밀 도출 과정을 메인 회로 실행과 분리하고, 첫 번째 상호작용이 발생하는 즉시 그 결과를 클러스터 노드에 로컬로 캐싱합니다. 그 결과, 사용자와 MXE 간의 반복적인 상호작용 시 경량 로컬 조회 기능을 통해 캐시된 비밀을 재사용하게 되며, 이를 통해 다크 풀(dark pool)과 같은 암호화 애플리케이션의 응답성이 크게 향상될 뿐만 아니라 회로 크기를 줄이고 애플리케이션 로직을 위한 연산 자원을 확보할 수 있습니다.
서론
Arcium은 블록체인, AI, 기업 및 정부 분야의 애플리케이션을 위해 완전히 암호화된 데이터에 대해 신뢰가 필요 없는 확장 가능한 MPC(다자간 연산) 기반 실행을 제공하는 암호화 컴퓨팅 네트워크입니다. Arcium 네트워크는 각각 소수의 노드로 구성된 다수의 MPC(다자간 연산) 클러스터로 이루어져 있습니다. 클러스터는 데이터가 전체적으로 암호화된 상태를 유지한 채로 데이터를 처리할 수 있으며, 어떤 노드(또는 노드 집합)도 평문 데이터를 볼 수 없습니다. 프로그램이 클러스터와 상호작용하려면 일련의 (암호화된) 명령어를 선언하고 MXE(다자간 실행 환경)를 초기화해야 합니다. 전형적인 앨리스와 밥(Alice and Bob) 설정에서 MXE를 앨리스로 생각할 수 있으며, 앨리스가 보유한 모든 데이터는 클러스터에 의해 처리됩니다. 즉, 클러스터 내 최소 한 개의 노드가 정직하게 행동하는 한 데이터는 암호화된 상태로 유지됩니다. 예를 들어, 암호화된 주문 장부가 온체인에 저장되어 있고 사용자가 암호화된 주문을 전송하여 해당 암호화된 다크 풀과 상호작용을 원하는 다크 풀 프로그램을 생각해 봅시다. 이는 전용 암호화 명령어를 통해 가능해집니다. 이 예시에서 MXE/클러스터는 주문 장부를 암호화하는 개인 키를 보유합니다(MXE 외에는 아무도 이를 복호화할 수 없으며, 복호화되더라도 어떤 노드도 평문 데이터를 볼 수 없습니다). 또한, MXE는 사용자가 안전한 채널을 생성하여 상호작용할 수 있도록 하는 개인 키/공개 키 쌍을 보유합니다. 즉, 사용자와 MXE는 각자의 개인 키와 상대방의 공개 키를 사용하여 디피-헬만(Diffie-Hellman) 키 교환을 수행함으로써 공통의 공유 비밀을 도출합니다. 공유 비밀이 설정되면 양측은 데이터를 로컬에서 암호화하여 비보안 채널을 통해 전송할 수 있으며, 상대방이 이를 복호화할 수 있습니다. 유일한 차이점은 MXE가 표준 모델에서 앨리스와 같은 역할을 수행함에도 불구하고, 복호화한 후에도 처리하는 데이터를 전혀 볼 수 없다는 점입니다. 따라서 사용자는 자신의 소중한 데이터를 암호화하여 신뢰하는 친구인 앨리스에게 보낼 수 있으며, 앨리스는 이를 안전하게 처리하게 됩니다.
제한 사항
더 강력한 암호화 요구 사항을 충족하기 위해, 설정된 공유 비밀키는 대개 안전한 암호화 해시 함수를 사용하여 해시 처리됩니다. 이 작업은 사용자에게는 매우 빠르게 느껴지지만, MXE 입장에서는 무시할 수 없는 수준의 연산 자원을 필요로 하며, 명령어당 최대 1초의 오버헤드가 발생합니다. 이러한 추가적인 지연 시간은 사용자의 애플리케이션 사용 경험에 심각한 악영향을 미칠 수 있습니다.
한 가지 가능한 최적화 방안은 공유 비밀번호의 계산 과정을 실제 계산(즉, 주문장부에 주문을 등록하는 작업)과 분리하고, 노드에서 매우 정교한 캐싱 로직을 결합하는 것입니다. 회로와 제공된 입력값(즉, 사용자의 공개 키)을 바탕으로, 노드는 공유 비밀번호를 도출하는 데 사용된 클라이언트 공개 키를 추론할 수 있습니다. 그런 다음 클러스터의 각 노드는 캐시된 공유 비밀의 해당 몫을 로드합니다. 만약 MXE에 암호화된 데이터를 제출하는 사용자 중 누구에 대한 공유 비밀(또는 그 일부)도 캐시에 없는 노드가 있다면, 클러스터는 먼저 공유 비밀을 계산하는 연산을 수행하고(이때도 노드 집합 중 어느 것도 실제로 공유 비밀을 볼 수는 없음), 각 노드가 이를 캐시에 추가하도록 한 다음, 실제 연산을 실행합니다. 이후 사용자가 MXE와 상호작용할 때는 공유 비밀이 캐시에 존재하므로, 계산 시간이 상당히 단축될 것입니다.
구현
당사의 고급 캐싱 메커니즘을 지원하기 위해, 먼저 내부 Arcis 컴파일러를 개편하여 이제 명령어가 사용자 암호화 입력, 즉 도출해야 하는 공유 비밀을 필요로 하는지 자동으로 감지하도록 했습니다. 개발자가 구현하는 모든 명령어에 대해, 컴파일러는 중간 표현(IR)에 소위 ‘식(Expressions)’을 추가합니다. 명령어가 컴파일되면, 컴파일러는 IR에 대해 대대적인 최적화를 수행한 후 Arcis MPC 엔진이 이해하고 처리할 수 있는 형식으로 회로를 출력합니다. 이전에는 공유 비밀의 계산을 담당하는 빌딩 블록이 항상 인라인 처리되어 중간 표현에 전체적으로 추가되었습니다. 이 부분만으로도 실제 계산에 최대 1초의 오버헤드가 발생했습니다. 최신 최적화를 통해 이제 기본적으로 전체 키 교환을 인라인 처리하지 않습니다. 대신 공유 비밀 정보를 담고 있는 단일 표현식을 IR에 추가합니다. 왜 실제 공개 키가 아닌 n번째 입력 공개 키일까요? 그 이유는 회로가 실제로 처음 실행되기 훨씬 전에 컴파일되기 때문입니다. 즉, 사용자 공개 키는 런타임 값이며 컴파일러는 이를 알 수 없습니다. 런타임에 사용자가 제공하는 공개 키와 컴파일된 회로가 결합되는 지점은 노드입니다. 회로를 검사함으로써, 노드는 공유 비밀을 로드하거나 도출하는 데 필요한 정적 공개 키 목록과 회로에 제공된 실제 입력 공개 키를 매칭할 수 있습니다.

개선 사항
이 최적화의 주목할 만한 점은 최악의 경우에도 사실상 체감되는 오버헤드가 거의 없으며, 두 번째 사용부터는 누적되어 상당한 이점을 가져온다는 것입니다. 다크 풀 예시로 돌아가 보면, 특정 사용자가 처음 암호화된 주문을 제출할 때 노드들은 이전과 마찬가지로 공유 비밀키를 도출하지만, 이를 나중에 재사용하기 위해 캐시한 다음 실제 암호화된 주문 삽입으로 넘어갑니다. 그러나 그 사용자와 다크 풀 간의 이후 모든 상호작용에서는 키 도출 과정을 완전히 건너뜁니다. 노드들은 단순히 캐시된 공유 키를 재사용하여 바로 실제 작업, 즉 암호화된 주문 장부에 암호화된 주문을 삽입하는 단계로 넘어갑니다. 구체적으로 말하면, 공유 비밀번호 도출은 노드 간에 이루어지는 비사소한 MPC(다자간 계산) 프로토콜입니다. 현재 설정에서는 이로 인해 모든 명령어마다 약 1초의 오버헤드가 발생합니다. 제안된 최적화를 적용하면, 첫 번째 상호작용 이후 그 1초는 단일 로컬 캐시 조회로 축소됩니다. 다크 풀에 10건의 주문을 제출하는 사용자의 경우, 누적 지연 시간이 약 9초 단축되는 셈입니다.

두 번째 장점은 Arcium 스택 전반에 걸쳐 관심사를 더 명확하게 분리할 수 있게 된다는 점입니다. 개발자와 Arcis 컴파일러는 더 이상 공유 비밀 키 도출을 모든 회로의 인라인 조각으로 취급할 필요가 없습니다. 공유 키 관리는 개발자와 Arcis의 책임 영역에서 벗어나, 실제 위치인 즉, 사용자와 MXE를 직접 운영하는 클러스터 사이로 이동합니다. 부수적인 효과로 회로가 더 가벼워집니다. 공유 키 도출이 더 이상 회로에 컴파일되지 않으므로 회로 크기가 줄어들고, 동일한 명령어 내에서 개발자의 실제 로직을 위해 더 많은 Arcium 연산 유닛을 확보할 수 있게 됩니다.
또한 이번 변경 사항은 완벽한 하위 호환성을 갖추고 있습니다. 노드는 각 회로를 검사하여, 공유 키 도출이 인라인으로 처리되든 별도의 키 도출 및 캐싱 방식으로 처리되든 상관없이 적절한 경로를 자동으로 선택합니다.
사용자 입장에서는 이 과정이 완전히 투명하게 진행됩니다. 새로운 절차가 추가되는 것은 아니며, 다크 풀에 제출된 두 번째 주문이 첫 번째 주문보다 눈에 띄게 더 빠르게 처리되는 것을 느낄 수 있고, 그 이후의 모든 주문도 계속해서 신속하게 처리됩니다. 개발자의 관점에서 보더라도 코드 수준에서는 이 업그레이드가 전혀 눈에 띄지 않습니다. 명령어를 다시 작성할 필요가 없으며, 업데이트된 컴파일러로 재컴파일하기만 하면 됩니다. 그러나 이로 인한 이점은 매우 뚜렷합니다. 지연 시간이 줄어들고 명령어당 처리 능력이 증가함에 따라 사용자 경험이 더욱 매끄러워지며, 이는 더 많은 사용자 유입, MXE의 활동 증가, 그리고 궁극적으로 해당 MXE를 기반으로 한 더 많은 기회로 이어집니다. 노드 운영자 또한 이번 업그레이드의 혜택을 누리게 되는데, 캐싱을 위한 로컬 스토리지와 같이 풍부하게 보유한 자원을, 실제로 병목 현상이 발생하는 대역폭과 교환하게 되기 때문입니다. 그 결과 동일한 하드웨어에서 단위 시간당 더 많은 명령어가 처리되며, 이에 따라 수익도 증가합니다.
과제
공유 비밀번호를 캐싱하는 데에는 몇 가지 장단점이 따르며, 그중 가장 큰 단점은 명백합니다. 즉, 특정 MXE와 상호작용하는 고유 사용자 수가 늘어날수록 캐시 상태 정보의 양도 함께 증가한다는 점입니다. 수천 명의 활성 트레이더가 이용하는 인기 있는 다크 풀의 경우, 노드들은 사용자당 공유 비밀번호의 일부를 보관해야 하며, 이는 규모가 커질수록, 그리고 노드가 동시에 처리하는 여러 MXE에 걸쳐 누적됩니다.
부적절한 캐싱 방식은 캐싱 기반 서비스 거부(DoS) 공격의 빌미를 제공할 수 있습니다. 악의적인 사용자는 새로 생성된 키 쌍을 사용하여 MXE와 반복적으로 상호작용함으로써, 노드들이 매 명령어마다 완전히 새로운 공유 비밀을 도출하도록 강요하고, 결코 재사용되지 않을 항목들로 캐시를 불필요하게 부풀릴 수 있습니다.
해답은 신중하게 설계된 캐시 제거 정책에 있습니다. 모든 항목을 동등하게 취급하기보다는, 이 정책은 반복적이고 정당한 사용을 우대하여 MXE와 적극적으로 상호작용하는 사용자를 위해 공유 비밀 정보를 캐시에 유지해야 합니다.
보도자료
공유 비밀번호 캐싱 기능은 곧 출시될 Arcium 릴리스의 일부로 제공될 예정입니다. 이 기능이 적용되면 개발자들은 최신 CLI를 사용하여 암호화된 명령어를 재빌드하기만 하면, 해당 노드 버전으로 업그레이드된 모든 클러스터에서 최적화 효과를 누릴 수 있습니다. 앞서 설명한 하위 호환성 노드 로직 덕분에 기존 배포 환경은 변경 없이 계속 작동하므로, 업데이트 과정이 매우 원활하게 진행될 것입니다.












.jpg)
