무엇이 실제로 트랜잭션을 막는가

모든 보관 제품에는 통제 수단을 나열한 기능 페이지가 있습니다. 허용 목록, 지출 한도, 시간 잠금, 승인 흐름, IP 제한. 전부 실재하고 전부 유용합니다. 하지만 이들이 모두 같은 종류는 아니며, 서로 바꿔 쓸 수 있는 것처럼 다루는 것이야말로 조직이 마케팅이 암시한 것보다 약한 보안 모델에 이르는 길입니다.

이들을 깔끔하게 갈라놓는 질문이 하나 있습니다. 시스템의 모든 소프트웨어가 틀렸거나 적대적이라면, 이 통제는 그래도 버틸까?

목록의 대부분에 대한 답은 아니오입니다. 정확히 하나에 대한 답은 예입니다. 이 글은 그 둘을 가려내는 이야기입니다.

한 층이 아니라 세 층

누군가 자금을 옮기려는 순간부터 자금이 실제로 움직이기까지, SSP Enterprise에는 서로 다른 세 개의 장벽이 있습니다. 이들은 다르게 무너지고, 어느 것이 어느 것인지 아는 것이 요점의 전부입니다.

이 층들은 유용함 순으로 늘어놓은 것이 아닙니다. 그것을 무너뜨리는 데 무엇이 필요한지의 순서입니다.

1층: 조율 계층

정책 엔진이며, 기능의 대부분이 여기에 삽니다. SSP Enterprise는 주소 허용 목록, 목적지 유형 제한, 금액 임계값을 넘는 트랜잭션을 지연시키는 시간 잠금, 일정 금액을 넘으면 관리자 승인을 요구하는 규칙, 조직 접근에 대한 IP 제한을 지원합니다. 정책 템플릿은 합리적인 사전 설정을 주고, 그것이 이후 실제로 편집 가능한 규칙으로 구체화됩니다.

이들은 진짜 일을 합니다. 허용 목록은 잘못 입력한 주소가 제안이 되는 것조차 막습니다. 시간 잠금은 재무 팀에게 뭔가 잘못됐음을 알아챌 창을 줍니다. 승인 규칙은 큰 송금을 한 사람의 오후가 아니라 두 사람의 대화로 바꿉니다.

이들이 아닌 것은 보관의 강제입니다. 이 규칙들은 SSP의 소프트웨어에 살고 SSP의 서버가 평가합니다. 볼트 주소의 일부가 아니며, 블록체인은 이들에 대해 들어 본 적조차 없습니다. 정책 엔진이 우회된다면 — 버그로든, 침해된 서버로든, 적대적인 운영자로든 — 규칙은 그냥 적용되지 않습니다.

이것을 분명히 말하는 이유는 그 반대가 더 나쁘기 때문입니다. 자기 허용 목록이 보관 보장이라고 믿는 팀은 그에 맞춰 임계값을 정할 것이고, 그것이 바로 견딜 수 있는 사고를 견딜 수 없는 사고로 바꾸는 실수입니다.

2층: 당신의 기기

두 번째 장벽은 각 서명자가 지닌 기기 한 쌍이며, 중요한 지점에서 첫 번째보다 강합니다. SSP도 믿지 않는다는 점입니다.

제안이 서명자에게 도달하면, 그의 기기는 트랜잭션의 원시 바이트를 로컬에서 디코딩하고 그 결과를 화면에 표시되는 것과 대조합니다. 수신자, 금액, 토큰 — 서버의 설명에서 가져오는 것이 아니라 바이트에서 읽어 냅니다. Solana에서 이 대조는 명시적이고 가차 없습니다. 디코딩된 바이트가 표시된 내용과 어긋나면 서명은 경고로 끝나지 않고 강하게 차단됩니다. 그 지점의 불일치는 렌더링 오류가 아니라 진행 중인 공격을 뜻하기 때문입니다.

기기는 수수료 상환에 대해 자체적인 독립 상한도 적용합니다. relay가 수수료를 제안하지만, 지갑은 relay가 무엇을 주장하든 코드에 박힌 최댓값을 넘는 수수료의 서명을 거부합니다. 이는 relay가 전적으로 적대적이더라도 수수료 경로를 통한 유출을 한계 짓습니다. 시뮬레이션 또한 승인 전에 돌아가, 제안을 현재 체인 상태에 대해 실행해 검토 화면이 그 트랜잭션이 실제로 무엇을 할지 보여 주게 합니다. 이는 트랜잭션 시뮬레이션과 위험 경고와 함께 도착했습니다.

이 계층은 침해된 서버를 이깁니다. 이기지 못하는 것은 침해된 기기, 그리고 읽지 않고 승인하는 서명자입니다. 또한 서명자의 두 기기를 모두 요구하는데, 사람당 2-of-2가 의미를 갖는 이유가 여기 있습니다. 2층은 두 기기 중 약한 쪽만큼만 강하고, 그 둘은 의도적으로 서로 다른 종류의 하드웨어입니다.

3층: 체인

세 번째 장벽은 다른 모든 것이 무너졌을 때 버티는 유일한 것입니다.

볼트의 주소는 서명자 집합과 승인 임계값에서 파생됩니다. 필요한 수의 유효한 서명을 담지 않은 트랜잭션은 거절된 트랜잭션이 아니라 무효한 트랜잭션입니다. 네트워크의 모든 노드가 독립적으로 같은 결론에 이르고, SSP 인프라에 대한 접근이 아무리 깊어도 그 산수는 달라지지 않습니다.

그래서 임계값이 볼트를 만들 때 가장 깊이 생각할 가치가 있는 숫자이고, 그래서 나중에 수정할 수 없습니다. 첫 기업용 볼트 설정하기가 절차를, 2-of-2 대 2-of-3 대 m-of-n이 숫자를 고르는 법을 다룹니다.

각 층은 어디서 무너지는가

실패 양상을 나란히 놓으면 설계할 일이 명확해집니다.

상황	조율 계층	당신의 기기	체인
서명자가 주소를 잘못 입력한다	막는다	읽는다면 막는다	상관하지 않는다
서명자가 피싱에 걸려 승인한다	허용 목록에 없으면 막는다	진실을 보여 준다. 그래도 승인할 수 있다	상관하지 않는다
SSP의 relay가 침해된다	무너진다	버틴다 — 바이트는 로컬에서 디코딩된다	버틴다
SSP의 정책 엔진에 버그가 있다	무너진다	버틴다	버틴다
서명자의 노트북이 침해된다	이를 위한 설계가 아니다	부분적으로 — 휴대폰은 여전히 검증한다	버틴다
공격자가 M 미만의 서명자를 쥔다	이를 위한 설계가 아니다	버틴다	버틴다
공격자가 M 이상의 서명자를 쥔다	무너진다	무너진다	무너진다

마지막 줄이 이 모델의 정직한 바닥입니다. 멀티시그는 당신의 서명자 가운데 소수가 침해되는 것으로부터 지켜 줍니다. 다수로부터는 지켜 주지 않으며, 어떤 제품도 거짓말 없이 그 반대를 주장할 수 없습니다. 그래서 임계값과 서명자들의 독립성이 어떤 기능 목록보다 중요합니다.

이것이 구성 방식에 뜻하는 바

3층만으로 안전하도록 볼트를 설계하세요. 정책 엔진이 없는 셈 치고 임계값과 서명자 집합을 고르세요. 그 답이 불편하다면, 고칠 것은 다른 임계값이나 다른 서명자이지 더 많은 정책이 아닙니다.

그다음에 정책이 잘하는 일을 위해 정책을 더하세요. 허용 목록은 사람의 실수를 잡습니다. 시간 잠금은 반응할 시간을 사 줍니다. 승인 규칙은 큰 금액에 두 번째 눈을 만듭니다. 이들은 프로세스 개선이고 실제로 사고를 줄입니다. 다만 공격자와 당신의 금고 사이에 서 있는 것이 아닐 뿐입니다.

서명자들을 진짜로 독립적으로 유지하세요. 같은 노트북, 같은 건물, 같은 복구 방식의 두 서명자는 둘보다 하나에 가깝습니다. 3층의 힘은 M명의 서로 다른 사람을 M쌍의 서로 다른 기기와 함께 침해해야 하는 어려움에서 나옵니다.

서명자들이 검토 화면을 실제로 읽게 하세요. 2층은 그럴싸해 보이지만 잘못된 제안을 잡아낼 수 있는 유일한 장벽이고, 사람이 자기 기기가 디코딩한 내용을 들여다볼 때만 작동합니다. 볼트를 만들 때 왕복을 한 번 연습해 두면 아무것도 걸려 있지 않을 때 그 습관이 자랍니다.

다른 보관 제공자에게도 같은 질문을 하세요. SSP를 쓰든 안 쓰든 이 틀은 옮겨 갑니다. 기능 페이지의 각 통제에 대해, 제공자 자신의 소프트웨어가 틀려도 살아남는지 물으세요. 답은 종종 배울 것이 많고, 명확하게 답하는 제공자는 자기들이 어떻게 사고하는지에 대해 좋은 것을 말해 주고 있는 것입니다.

여러 키로 구성한 체계가 실무에서 어떻게 허물어지는지는 멀티시그 실패 양상과 SSP의 완화 방식이 하나씩 짚고, SSP Enterprise: 팀을 위한 멀티시그 볼트가 조각들이 어떻게 맞물리는지에 대한 조망입니다.