작성: SHEKAR RAMASWAMY 편집: Cointime.com 237

암호화폐 생태계 진입 장벽을 낮추기 위해 많은 기업들이 개인 키 관리를 간소화하는 솔루션을 연구하고 있습니다. 이러한 솔루션 중 다수는 비수탁형이라고 주장하지만 이러한 솔루션은 사용자의 개인 키에 대한 액세스 권한을 얻거나 이를 잃을 수 있습니다. 법적 회색 영역을 악용하고 보안과 사용자 경험 사이의 중간 지점으로 자신을 잘못 배치합니다...

보다 안전한 암호화폐 생태계를 위해서는 비수탁 서비스에 대한 가이드라인을 개선해야 합니다. 특히 관리되지 않는 서비스를 정의하려면 더 엄격한 규칙이 필요합니다. 비수탁 서비스를 선택하는 경우 개인 키가 제3자의 위험으로부터 영구적으로 안전하다는 사실을 알고 안심할 수 있어야 합니다. 이 문서에서는 관리되지 않는 서비스에 세 가지 요구 사항이 있어야 한다고 결론을 내립니다.

사용자는 개인 키에 액세스할 수 있습니다.

서비스는 개인 키에 액세스할 수 없습니다.

서비스는 개인 키를 잃지 않습니다.

MPC(Multi-party Computation)는 이러한 세 가지 요구 사항을 달성하는 데 사용할 수 있는 암호화 기술입니다.

MPC는 어떻게 작동합니까?

간단히 말해서, #fancymath(고급 수학)를 사용하면 개인 키를 여러 개의 "공유"로 분할하고 신뢰할 수 있는 당사자 간에 배포할 수 있으며 어느 당사자도 완전한 개인 키를 볼 수 없습니다. 일반적으로 사용되는 설정은 다음과 같이 "2-to-3 MPC 방식"입니다.

1개의 공유가 사용자의 장치에 저장됩니다.

1주는 제3자(보통 지갑)가 보유합니다.

기기를 분실한 경우를 대비하여 1개의 백업 공유가 사용자에게 이메일로 전송됩니다.

이 시나리오에서는 총 3개의 공유가 있습니다. 각 공유는 트랜잭션 개체에 부분적으로 서명할 수 있습니다(공유는 개인 키의 일부일 뿐이므로). 3개의 공유 중 최소 2개의 공유는 부분 서명을 제공해야 하며, 그런 다음 전체 서명으로 결합되어 블록체인에 제출될 수 있습니다. 전체 프로세스는 MPC 알고리즘으로 간주됩니다.

사용자가 작업을 수행하려는 경우 평소와 같이 지갑을 사용하여 트랜잭션에 서명합니다. 후드 아래에서 지갑은 전체 개인 키에 액세스할 수 없지만 MPC 프로토콜을 사용하여 공유를 병합하지 않고 트랜잭션에 서명합니다(자세한 내용은 아래 참조). 따라서 타사 지갑은 서버에서 두 번째 또는 세 번째 공유를 "볼" 수 없으므로 사용자 계정을 인수하는 것이 불가능합니다.

사용자의 기기를 도난당하거나 제3자가 해킹을 당하더라도 3개의 공유 중 1개만 손실되므로 사용자가 제어할 수 있습니다. 물론 이 두 가지가 동시에 일어나면 곤란하다.

이 접근 방식이 관리되지 않는 솔루션에 대한 기준도 충족한다는 점은 주목할 가치가 있습니다.

1. 사용자는 제3자 또는 백업 키를 사용하여 개인 키의 2/3를 얻을 수 있습니다.

2. 공유가 1개뿐이기 때문에 제3자는 개인 키에 액세스할 수 없습니다.

3. 공유가 1개뿐이므로 제3자는 개인 키를 잃지 않습니다.

MPC 스마트 계약 지갑(SCW)

스마트 계약 지갑이 다중 사용자 트랜잭션 및 지출 한도와 같은 기능을 통해 더 나은 사용자 경험을 제공하는 방법에 대해 이미 이야기했습니다. 그러나 결국에는 여전히 스마트 계약이며 트랜잭션을 시작하려면 EOA가 필요합니다.

EVM(Ethereum Virtual Machine)은 개인 키로 서명된 트랜잭션만 지원합니다. 스마트 계약에는 개인 키가 없기 때문에 트랜잭션을 생성할 수 없습니다! 따라서 EOA만이 스마트 계약을 호출하는 트랜잭션을 생성할 수 있습니다.

스마트 계약 지갑이 작동하는 방식에 대한 다이어그램은 다음과 같습니다.

MPC는 "여전히 EOA가 필요한 문제"를 완전히 해결하지는 못하지만 트랜잭션을 시작하는 프로세스를 더 안전하고 쉽게 만듭니다. 사용자는 더 이상 자신을 대신하여 개인 키를 보유하는 제3자를 신뢰할 필요가 없으며 개인 키를 보호하는 방법에 대해 걱정할 필요도 없습니다. 이제 다음과 같은 이점을 얻을 수 있습니다.

이 그림은 이전 그림보다 더 복잡하지만 최종 사용자를 괴롭히지 않도록 구현에서 복잡성을 추상화했습니다. 핵심 결과는 보다 최적화된 사용자 경험입니다.

결론적으로 최고의 Web3 경험을 제공하기 위해서는 MPC와 SCW를 함께 사용해야 합니다. Portal 및 ZeroDev의 협업과 같은 일부 사람들은 이미 이에 대해 작업하고 있습니다.

추가 읽기

일부(Vitalik 포함!)는 SCW가 MPC보다 훨씬 우수하며 두 가지를 혼합해서는 안 된다고 주장합니다. 이 트윗을 확인하고 토론에 참여하세요.