Weekly Livestream 2022년 9월 2일 - 보안

Alejo:이번 주에는 아주 특별한 손님이 있습니다: 로버트. 그는 세계 최고의 Move 감사원이며 보안 전문가 중 한 명입니다. 그는 많은 프로젝트와 핵심 프로토콜을 감사했습니다. 우리는 로버트와 함께 일하게 되어 매우 기쁩니다.

로버트:불러주셔서 감사합니다! 저는 스마트 계약 감사 회사인 OtterSec 의 운영을 돕고 있습니다. 우리는 Move의 내부를 많이 살펴보고 VM 계층과 Aptos 특정 SDK 계층 모두에 대해 깊이 이해하려고 노력중입니다. 이를 통해 보안영역의 특정 측면을 보장할 수 있도록 노력입니다. 과거에 우리는 Alameda Research, Jump Crypto와 같은 대규모 기관과 긴밀하게 협력했으며 Pontem Foundation과도 컨테이너 계약을 통해 핵심 코드를 감사했습니다. 저는 보안에 중점을 두고 있기 때문에 Pontem과 협력하여 애플리케이션을 보호하는 방법에 대해 더 많이 이야기하게 되어 기쁩니다.      

Alejo: 와줘서 고맙습니다. 우리의 대화의 시작은 Move의 어떤 점이 마음에 드는지부터 시작할 수 있습니다. 어떻게 다르며 어떻게 비슷한지 혹은 보안 분야에서 어떤 패러다임의 변화를 주는지?

로버트:정말 좋은 질문입니다. 언어로서의 무브(Move as a language)는 매우 흥미롭다고 생각합니다.  저는 블록체인을 위해 Move Rust라고 부를 것입니다. 이것은 도메인 별로 다르며, 이는 Rust가 가지고 있는 많은 범용 문제를 피할 수 있음을 의미합니다. 예를 들어 Move를 사용할 때 데이터를 수동으로 직렬화하거나 역직렬화할 필요가 없습니다. 개발자에게 더 안전한 프로그램을 작성할 수 있는 더 많은 도구를 제공하는 훨씬 높은 수준의 언어입니다.  

좀 더 전문적인 답변을 드려도 되나요? Move의 정말 멋진 특징 중 하나는 VM이 ​​[versatile : 다기능적]이 매우 뛰어나다는 것입니다. 이에 대한 한 가지 예는 references가 Move VM 자체의 첫 번째 클래스 값(first class value)인 것처럼 기본적으로 사용 가능하다는 것입니다. 따라서 예를 들어 바이 코드(bi-code)에서 스택의 references를 푸시하고 references를 직접 dereference할 수도 있습니다. 이것의 의미는 함수를 호출하려는 경우 references를 직접 전달한다는 것입니다. 일반적으로 무브(Move)는 도메인별, 블록체인별로 훨씬 높은 수준의 언어하고 생각되며, 일반적인 프로그래밍에서 볼 수 있는 많은 보안 문제를 해결한다고 생각합니다.

Alejo: 좀 더 깊이 얘기해보겠습니다. 첫 번째 클래스 값(first class value)이 된다는 것이 무엇인가요?

로버트:좋은 질문입니다. 첫 번째 클래스는 가상 시스템에서 기본적으로 지원이 된다는 의미입니다. 예를 들어, Rust로 데이터를 역직렬화(deserializing)하려면 해당 값에 대한 일종의 중간(intermediate) 표현이나 기본 바이트에서 프로그램이 사용 가능한 것으로 변환하기 위한 일종의 표현을 가질 수 있어야 합니다. 한마디로 기본 바이너리에서 사용 가능한 Rust 값으로 변환하는 중간 단계가 필요합니다. 반면 Move는 값을 직접 사용하여 이 단계를 완전히 무시합니다.

Alejo: 음.. 제가 좀 더 이해할 수 있도록 질문을 드리자면 ETH는 네이티브인가요? Compound 또는 UNI 토큰은 퍼스트 클래스 값인가요? 이더리움과 비교하면 어떻습니까?

로버트:ETH의 경우 계약(contract)이 있고 값을 로드(load)하려면 백엔드가 있어야 하므로 실제로 더 높은 수준의 구조 자체에 대한 first class 액세스 권한이 없습니다. 예를 들어 토큰에 대한 레퍼런스(reference)를 실제로 전달할 수 없습니다. 값을 받으려면 계약(contract)을 호출해야 합니다. 여전히 중간 단계가 존재하지만 모든 계약의 상태가 계약 자체에 저장되기 때문에 약간 다릅니다.  

Alejo: 그럼 ERC-20 컨트랙트처럼 컨트랙트를 불러야 하나요?

로버트: 네.

Alejo: 그것이 더 효율적인가요? 안전뿐만 아니라 가스비도 아낄 수 있나요?

로버트: 음.. 그 부분은 가스 절약과는 별개라고 생각해요. 언어로서의 무브(Move as language)는 매우 빠르게 디자인되었다고 생각합니다. 확장성이 뛰어나기 때문에 사용자의 가스 비용도 더 저렴해야 합니다. 가스는 VM의 기본 개념과 비슷하지만 MOVE 가스는 ETH 또는 Solana 가스와는 완전히 다른 단위로 표시됩니다.

Alejo: 좀 더 추상적으로 비교해 보죠. 만약 우리가 이것들을 코스모스나 폴카닷 같은 것에 나열해 놓는다면, 어떤 것이 더 나을까요? MOVE인가요? EVM인가요? 어떤 측면을 들여다 보아야 합니까?

로버트: 이론적으로 계약서(contracts)는 어떤 언어로든 쓸 수 있습니다. 이더리움이나 다른 여러 체인에서도 꽤 안전하다는 예가 많이 있습니다. 하지만 제가 생각하는 핵심은 MOVE가 기본적으로 더 안전하다는 것입니다. 기존보다 더 노력하지 않아도 되고, 주의를 기울이지 않고도 더 안전한 계약서를 작성할 수 있습니다.

Alejo: 그래서 당신이 말하는 것은 본질적으로 자기 무덤을 파는 그러한 일은 없다는 것이죠?

로버트: 그렇길 바라고 있지만 보장할 수는 없습니다. 이상적으로는 그렇습니다. Pontem이 보안에 대해 많은 관심을 갖고 있다는 것을 알고 있지만 솔직히 말해서 보안에 대해 별로 관심이 없거나 모든 의미를 이해하지 못하는 스마트 컨트렉트 개발자가 많다고 생각합니다. 그들은 가능한 한 빨리 메인넷에 배포하는 코드를 작성하면서 스스로 무덤을 파고 있습니다.

Alejo: 그렇다면 사용자들이 영향을 받지 않도록 하려면 어떻게 해야 할까요? 프로젝트에 대한 모범 사례는 무엇입니까? 사용자가 메타버스에서 안전한지 확인하기 위해 어떤 것을 확인해야 합니까?

로버트: 저는 사용자로서 여러분이 할 수 있는 가장 중요한 것은 경계를 늦추지 않는 것이라고 생각합니다. 많은 프로젝트가 있지만 여러분이 사용하는 프로젝트가 실제로 평판이 좋고 안전한지 그리고 전문 감사법인과 협력해서 그들의 컨트렉트를 감사받는 과정을 거쳤는지 확인하는 것이 중요할 것 같습니다. 이것이 보안 취약성에 대한 사용자 위험을 낮추는 가장 좋은 방법이라고 생각합니다. 물론 감사도 완벽하지는 않기에 항상 무엇인가를 놓칠 수 있는 가능성이 있지만 보안에 대한 전반적인 입장이나 팀의 자세는 정말 중요합니다. 저는 보안에 신경을 쓰는 팀을 접하는 것만으로도 훨씬 더 그 프로젝트에 확신을 갖게 됩니다.

추가로 Github 저장소에 대한 커밋(commit)과 감사 보고서에 대한 커밋(commit)을 비교해 볼 수 있습니다. 비교해서 차이가 있다면 팀과 지속적으로 참여해 왔는지? 또는 프로토콜에 감사에 의해 변경 되어야할 사항을 실제로 상의하지 않고 제품을 만들거나 Github로 밀어넣는다는 것을 알고 있는지 몇 가지 추가 질문을 해야 합니다.

Alejo: 프로토콜로서 우리가 그렇게 마음대로 할 수 있는 방법이 있습니까? 현재 Github에 올려진 버전이 감사가 끝난 버전이라는 것을 감사자로서 증명해줄 수 있습니까? 그리고 지갑도 증명해 줄 수 있나요?

Robert: 우리는 곧 Pontem을 위해 감사 보고서를 작성하겠지만 모든 감사 보고서에는 커밋 해시(commit hash)가 있습니다. 이 커밋 해시(commit hash)는 저희에 의해 스탬프가 찍혀 있고, 저희가 검토했다는 것을 증명합니다.

지갑에 대한 감사나 증명은 좋은 생각입니다. 지갑 앱에 기본적으로 사용자가 체인에 있는 이 코드를 실제로 감사원이 승인한 코드임을 확인할 수 있는 방법이 있다면 정말 좋을 것 같습니다. 간단히 예를 들어보자면 온체인에 있는 코드의 해시를 비교하는 것으로 구현해볼 수 있을 것 같습니다.

그 다음 이상적으로 사용자가 신뢰할 수 있도록 만들고싶은 경우 완전히 검증된 계약만 상호 작용하는 일종의 옵션을 만들 수 있습니다. 이런 방식을 채택하면 계약이 변경되었는지도 여부로 알 수 있습니다.

Alejo:정말 좋은 생각입니다. 우리는 그것을 한가지 기능으로 만들고 로드맵에 추가하는 방법을 찾을 것입니다. 이것 또한 지갑 보안에 대한 좋은 피벗입니다. 지갑이 메타버스로의 인터페이스라는 점을 고려해서 더 자세히 알려주시겠어요? 지갑 보안에서 무엇을 주의해야 할까요? 최근에 Solana 지갑에서 나타난 해킹에 대한 것을 다룰 것입니다. 당신의 의견과 사용자와 프로젝트가 자신을 해킹으로 보호할 수 있는 방법을 제시할 수 있습니까? 인터페이스로서의 지갑이나 중개자로서의 브라우저를 없애는 것에 대해 어떻게 생각하십니까?

로버트: 말씀드릴게 많겠네요! 첫 번째는 보안입니다. 저는 개인적으로 지갑의 보안이 오랫동안 관심 밖에 있었다고 생각합니다. 이제 사람들은 많은 관심을 가지고 dApp이 잠재적으로 손상되었다는 것을 많이 보았습니다. 하지만 Solana 해킹 이전에는 지갑이 감사되었는지 여부에 대해 아무도 신경 쓰지 않았습니다. 지갑은 전체 암호화 세계로 연결되는 다리역할이기 때문에 생각해보면 그다지 큰의미는 없습니다. 중앙 집중식 브리지가 손상되면 상호작용하는 모든 항목도 손상될 수 있습니다.

다시 Solana 해킹 이슈에 대해 이야기를 하자면 실제로 우리는 관련된 팀과 협력하고 있는 중이며 무슨 일이 일어났는지 알아내기 위해 그들과 협력하고 있습니다. 우리는 트위터에 우리가 발견한 것에 대한 보고서를 게시했습니다. 제 생각을 요약하자면 실수로 기록된 니모닉이나 비밀 키가 있었다는 것입니다. 우리는 이것이 사용자 키의 손상으로 이어질 수 있다고 생각합니다. 이러한 이슈에서 특히 중요한 것은 사용자 데이터를 다룰 때 더 더욱 조심해야 한다는 것입니다. 데이터가 실수로 모르는 곳에 남겨지지 않도록 해야합니다.

해당 이슈는 의도적으로 그것을 기록하려고하지 않았지만 실수에 의해 서버로 보내지는 객체에 저장되었습니다.

Alejo: 이러한 문제는 감사를 진행하는 중에 발견할 수 있는 것인가요?

로버트: 네, 하지만 저는 개발자들이 이런 일을 할 때 매우 조심해야 한다고 생각합니다. 특히 사용자 데이터가 의도하지 않은 방식으로 전달될 수 있는 이러한 사례를 찾는 데 많은 시간을 할애해야 합니다. 저는 이것이 일반적으로 지갑을 만들기 전부터 해야할 일이라고 생각합니다. 솔직히 말해서 지갑은 많고 많지만 그들 중 많은 프로젝트가 보안에 대해 그다지 신경 쓰지 않습니다. 우리는 실제로 팬텀(솔라나 지갑) 외에 다른 여러 지갑에 문제를 발견하고 보고했습니다. Solana에 대한 이슈와 함께 앞으로 지갑들도 보안에 더 신중해 질 것입니다.

Alejo: 이러한 패착의 책임은 크기 때문에 꽤 무섭습니다. 얼마나 많은 사람들이 이더리움에서 다른 지갑보다 메타마스크를 사용하는지를 생각해보세요. 우리는 이 문제를 어떻게 해결해야 할까요? 분산형 지갑 같은 것이 있나요?

로버트: 제 생각에는 사용자로서 보안에 신경쓰는 것이 해결책이라고 생각합니다. 강력한 보안 파트너가 있는 지갑으로만 작업하십시오. 지갑의 보안을 보장하기 위해 지갑이 무엇을 했는지에 대해 질문을 던지세요. 어쩌면 분산형 지갑을 가질 수도 있겠지만 그게 어떻게 작동하는지 잘 모르겠습니다. 제가 한 가지 고려하는 것은 지갑의 코드가 어느 정도 중앙 집중화되어야 한다는 것입니다. 저는 정말로 탈중앙화된 지갑 코드 기반을 가질 수 있는지 확신하지 못하고 있습니다.

Alejo: 그렇다면 지갑이 스마트 계약 dApp만큼 감사를 철저해야 하고 보고서를 공개해야 한다고 생각하나요?

로버트: 저는 지갑이 보안 측면에서 dApp보다 더 중요하다고 생각합니다. 사용자는 자신이 사용하고 있는 지갑이 서명하고 싶지 않은 거래에 실수로라도 서명하지 않아야하고, 모든 트랜잭션을 올바르게 표시한다는 확신을 가질 필요가 있습니다. 지갑은 확실히 보안에 신경을 많이 써야 하고 사용자들은 사용하는 지갑의 보안을 위해 노력해야 한다고 생각합니다. 결국 보안의 필요성은 사용자로부터 나옵니다. 사용자가 보안에 신경 쓰지 않는다면 지갑도 보안에 신경을 쓰지 않을 것입니다. 그러나 사용자가 보안을 요구한다면 지갑은 코드 감사를 받을 인센티브를 갖게 될 것입니다.

Alejo: 방금 생각난 질문입니다. 사람들이 지갑을 직접 다운로드하여 실행하면 어떻게 될까요? 어디에도 정보를 보내지 않는 것입니다. 그것이 작동할 수 있을까요? 아니면 컴퓨터나 전화 등에 추가 컴퓨팅이 필요하더라도 제3자를 신뢰할 필요가 없는 프레임워크가 있을까요? 이것은 Web2 : Web3에 대한 윤리적인 영역입니다.  Web2와 마찬가지로 모든 것을 추적하려고 합니다. 사용자가 클릭한 위치를 보고 싶습니다. 이 모든 로그는 제품 개선에 유용할 수 있지만 동시에 양날의 검이 되겠죠?

로버트: 네, 양날의 검입니다. Web2에서도 민감한 데이터를 로드하는 것과 관련하여 많은 우려가 있었다고 생각합니다. 하지만 Web2의 문제는 직접적으로 손실이 발생하지는 않습니다. 많은 사용자 이름과 암호를 훔친다 해도 Web3에 비해 돈에 직접적으로 액세스할 수 없었습니다. 하지만 Web3는 누군가의 지갑 개인 키가 있는 경우 즉시 자금을 고갈시킬 수 있습니다. 그래서 Web3가 훨씬 무섭다고 생각합니다.

Alejo: 네, 이해가 됩니다. 이것은 정말 좋은 피드백입니다. 솔직히 모든 웹사이트에서 우리는 이메일을 기록하거나 IP 주소를 기록해서는 안 됩니다. AWS 서버가 유용하다는 것을 알지만 그곳에 보내서도 안됩니다. 우리는 그것에 대해 이야기해보죠. 어떻게 하면 최소한의 정보만 수집하는 것을 만들 수 있을까요? 아무것도 수집(기록)한 것이 없기 때문에 유출이 일어나지 않게 할 수 있을까요?

로버트: 저는 그것이 사용자에게도 좋은 아이디어라고 생각합니다. 사용자 입장에선 제품 공급자가 데이터를 추적하는 것을 원하지 않습니다.

Alejo: 여기에는 단순히 개인 정보를 유출하는 것 이상의 우려가 있습니다. 중앙 집중화 또는 주요 지갑은 여러분의 거래를 기반으로 돈을 벌려고 하는 거래자에게 가치 있는 정보를 많이 제공하고 있음을 의미하기 때문입니다.. 사람들은 주파수를 통한 거래, Web2, 전통적인 금융에 익숙할텐데 그곳에서 발생하는 문제와 동일하게  "프론트 러닝", "백 러닝" 또는 “샌드위치 공격"이라고 부르는 또 다른 형태의 문제에 익숙해 질 것입니다. 이에 대한 당신의 생각도 듣고 싶습니다.

로버트: 네, 제 생각에도 그러한 정보가 있다면 잠재적으로 그럴 가능성이 있습니다.

제 경험으로 볼 때 대부분은 멤풀(Mempool)을 보거나 체인에서 무슨 일이 일어나고 있는지 관찰하고 이익을 위해 사용합니다.

*멤풀(Mempool)이란? 멤풀이란 아직 블록에 들어가지 않은 상태의 트랜잭션들이 어떤 공간에 있는 것을 의미한다.

Alejo: 지갑이 이런 정보를 전달하는 역할을 하지 않습니까? 저는 당신의 생각을 듣고 싶습니다. 게이트 키퍼 자체의 문제가 아니지만 거래는 게이트 키퍼를 거쳐야하고, 검증자는 어떤 블록이든 선택해야하는데.. 이것에 대한 당신의 의견을 듣고 싶습니다.

로버트:맞습니다. 지갑에 대한 결제 주문 흐름은 꽤 흥미롭다고 생각해요. 지금 당장 지갑이 그렇게 할 수 있을지 모르겠지만 가능할 것 같습니다. 제 기본적인 생각은 아마 검증자들이 MEV를 하는 사람들이 아닐 거라는 생각이 듭니다. 아마도 외부에서 찾을 수 있을 것입니다. 지갑은 플래시 스팟과 같은 거래를 스트리밍할 수 있는 어떤 시장이나 무언가에 연결될 텐데 지갑이 정직하려면 이렇게해선 안 된다고 생각합니다. 그것은 사용자와 사용자 간의 신뢰를 침해하는 행위입니다.

*MEV(Miner Extractable Value)란? 채굴자(혹은 validator, sequencer 등)는 블록을 생성하며 어떠한 트랜잭션을 포함시킬지, 제외시킬지, 혹은 재배열(re-order)할지를 마음대로 결정할 수 있습니다. MEV는 채굴자가 이러한 능력으로 창출할 수 있는 최대의 이익을 말합니다.

Alejo: 정직하지 않은 방법을 알고 있기때문에 누군가는 또 할 것이라는 것으로 들립니다. 왜 그것을 투명하게 하지 않을까요? 이런 일이 이미 일어나고 있으니 효율적으로 시장이 발전할 수 있도록  우리는 정직한 MEV를 허용할 수 있도록 합시다. 어떻게하면 안전한 술집을 만들 수 있을까요?

로버트: 옳은 말씀입니다. 주문 흐름과 블록 주문 중 어느 것이 더 중요한지 저도 잘 모르겠습니다. 저는 둘 다 중요하다고 생각하지만 대부분의 보상은 결국 검증자 스스로에게 돌아갈 것이라고 생각합니다. 왜냐하면 그들은 모든 거래를 받고 주문도 받기 때문입니다. 그리고 실제로 생성되는 블록을 제어합니다. 제 생각에 검증자들은 부정한 것을 지켜볼 것 같지 않습니다.

Alejo: 문제는 모든 사람이 메타마스크를 사용하고 메타마스크가 기본적으로 모든 것을 구분하지 않고 동일한 검증자에게 보낸다면 앞뒤가 안맞는 것처럼 보인다는 것입니다.

거래를 어떤 검증자에게 보냈는지 인식할 수는 있겠지만 그렇게 되면 당신의 거래가 훨씬 더 느리게 진행될 수도 있겠죠.

로버트: 단지 저는 지불 주문 흐름을 크게 보았을 때 Reddit에 큰 혼란이 있다고 생각합니다. 좋은 일은 아니라고 생각하며 사용자를 인식하는 측면에서 다소 위험하다고 생각합니다.

Alejo: 알겠습니다. 저는 두 가지 옵션을 생각해봤습니다. 어떤 형태로든 요금을 안내해서 사람들이 AWS 서버에 대해 선불로 지불하도록 하는 것과 사람들은 요금을 보지 못하지만 스프레드를 지불하는 것입니다. 어느 방식이든 비용이 얼마인지 투명하게 확인한 다음 사용자가 결정하도록 하면 된다고 생각합니다.

로버트: 저는 사용자들이 실제로 일어나고 있는 일의 양상을 이해하고 알고 있다면 그건 완전히 좋다고 생각합니다. 다만 사용자들에게 적절하게 전달되어야 합니다.

Alejo: 네. 감사합니다.

질문이 많이 들어왔는데요. 이것에 대해 이야기 나눠봅시다.

제프 - 연사: 저는 보안에 대한 이 주제를 좋아합니다. 특히 새로운 플랫폼의 경우 제 배경은 교육 분야이기 때문에 웹3 분야로 옮겼습니다. 저는 코호트(cohorts)를 운영하고 개발자를 교육하고 있습니다. 첫날부터 이야기한 것 중 하나는 안전한 계약과 인프라를 구축할 수 있는 다른 방법에 대한 것입니다. 이 질문에 대한 가장 좋은 대답은 당연히 감사와 검토를 원하지만 개발자에게 처음부터 모든 것을 테스트하는 상당히 표준화된 방법을 가르쳐야 한다는 것입니다. 좋은 배송을 원하는 만큼 빠른 배송과 사용자에게 안전하고, 강력한 코드를 배송하는 것 그 사이에서 균형을 찾아야 한다고 생각합니다. 당신이 몇 분 전에 말한 것처럼 한 번의 실수 때문에 당신은 누군가가 우연히 코드에서 무언가를 한다는 것을 알고 있고 당신이 수십억 달러에 대해 이야기하고 있다는 것을 들킬 수 있습니다.  그래서 저는 처음에 사람들이 안전의식을 갖도록 훈련시키는 방식이 필요하다고 생각합니다.

Alejo: 그 말씀은 제가 매일같이 생각하는 점입니다. 왜냐하면 전통적인 기술 배경에서 비롯된 정신은 빠르게 움직이고, 문제를 깨고, 그런 다음 실수로부터 배우고, 프로세스를 개선하는 것이기 때문입니다. 그러나 여기서 물건을 부수면 좋지 않습니다. 그래서 저는 이것에 대해 많이 고민해야 했고 로버트와 제프의 생각을 듣고 싶습니다.

제프 - 연사: 저는 Web3 Builders Alliance에서 일하고 있으며, 현재 코스모스에 있습니다. 우리는 MOVE 네트워크와 러스트 기반 스마트 계약 언어로 가고 있습니다. 우리는 상급 개발자가 되고자 하는 사람들을 위해 초보자가 아닌 마스터 수준의 코호트를 제공합니다.

Alejo: 우리는 앞으로 Cosmos에서 Move VM을 테스트할 것입니다. 우리는 Libra VM을 포크하고 Wassum과 호환되도록 만들고 Cosmos SDK를 사용하고 있었습니다. 그리고 Polkadot Parachain도 있습니다. Aptos에 여러분을 모시게 되어 매우 기쁩니다. 우리는 빠르게 움직이고, 제품을 빨리 부수는 것에 대해 쿠사마/폴카닷 생태계에서 배웠습니다. 두 가지 버전의 앱이 있다는 이 아이디어가 마음에 듭니다. 한 버전은 변경할 수 없으며, 누구도 해당 버전에 대한 다중 서명 액세스 형식을 가지고 있지 않다고 신뢰할 수 있습니다. 잘못된 부분이 있을 수 있지만 누구도 변경할 수 없는 버전입니다. 그러나 빠르게 배송할 수 있는 업그레이드 가능한 포크는 어떻습니까? 모든 사람에게 "이것은 완전히 감사되지 않았을 수 있습니다. 테스트 중입니다."라고 말할 수 있습니다. 이를 통해 우리는 빠르게 움직이고, 테스트하고, 실험하고, 깨뜨리고, 코드뿐만 아니라 우리가 가지고 있는 일부 가정 뒤에 있는 게임 이론까지 깨뜨릴 수 있습니다. 이것에 대한 당신의 생각이 궁금합니다.

로버트: 흥미로운 디자인이네요. 문제는 사용자가 이러한 위험을 평가하는 방법을 실제로 모른다는 것입니다. 스마트 계약을 사용하더라도 해킹당할 확률이 얼마나 되는지 알기는 매우 어렵습니다. 우리도 잘 모릅니다. 이 경우 동일한 앱의 두 가지 버전이 있고 하나는 더 안전하고 하나는 안전하지 않은 경우 더 많은 위험을 감수하려는 사용자가 지속적으로 제공되는 앱을 사용할 수 있다고 생각합니다. 그러나 현실적으로는 그들 중 하나라도 해킹을 당한다면 동일한 위기가 올 것이라 봅니다.

Alejo: 그런 의미에서 "this-thing-will-get-hacked.com"과 같은 "모든 곳에 자신의 위험을 감수하고, 당신이 잃을 수 있는 것보다 더 많은 돈을 넣지 말라”는 거대한 빨간 면책조항을 넣어둘까요?

제프: 인센티브화된 테스트넷도 좋은 모델입니다. 사람들이 테스트넷에 참여하고 피드백을 제공하도록 장려하고 유용한 토큰으로 보상하면 사용자 기반에 영향을 미치게 됩니다. 더 많은 토큰을 얻기 위해 테스트넷을 사용하여 모두가 이기고 있기 때문에 프로젝트에 이점이 있습니다. 참여자들에게 피드백을 받고 있으며 테스트넷을 사용하고 있습니다. 그들의 목표는 물건을 부수는 것입니다. 그들은 당신의 물건을 부수려고 함으로써 인센티브화된 테스트넷에서 더 많은 토큰을 얻습니다. 당신은 사용자의 감정적 요구에 부응합니다. 봐봐, "이건 쓰지마"라고 말하는 화면에 빨간색을 더 많이 칠할수록 전체 degen이 더 많이 들어와서 사용하게 될 것입니다. 그냥 "이리 와서 사용하고 부수면 토큰을 드리겠습니다."라고 말하는 것이 좋습니다.

Alejo: 그리고 다른 사람에게 현상금을 걸 수도 있습니다. 예를 들어, 만약 당신이 그것을 부숴버리면, 이 스테이크해 줄 수 있다.

제프: 물론이죠. 보통 그런걸 "바운티"라는 단어로 표현합니다. 이 얘기를 듣는 사람들은 그렇게 하려면 개발자가 되어야 한다고 생각할 수도 있습니다.. 당신은 반드시 들어와서 당신의 물건을 망가뜨리려고 하는 개발자들만을 원하는 것이 아니라, 일반 사용자들이 당신의 물건을 함부로 사용하고 기술적인 관점이 아닌 사용자 입장에서 그것을 망가뜨리려고 시도하기를 원할 것입니다.

Alejo: 이 인센티브화된 테스트넷의 아키텍처에 대해 생각하는 방식에는 별도의 네트워크를 만드는 두 가지 방법이 있습니다. 자신의 노드를 스핀업할 수 있습니다. 나는 가치가 없다면 스팸을 방지할 기능이 없다는 것이 문제라고 생각합니다. 그래서 내가 Kusama는 실제 가치가 있기 때문에 그 아이디어를 좋아하는 것입니다.

제가 생각하는 큰 차이점은 Aptos 메인넷에서 시작한 경우와 devnet에서 실행한 경우입니다.  Aptos devnet의 사람들은 트랜잭션을 보내기 위해 Aptos 토큰이 필요하기 때문에 스팸을 보낼 수 없다는 것입니다. 따라서 개발자는 devnet 환경에서 DDoS 공격을 경험할 수 없을 것입니다. 데브넷에서 부서지지 않았던 것들이 실제 환경에서 부서질 수 있고, 실제 환경에서 사기나 공격에 대한 것들을 전혀 경험할 수가 없을 것입니다.

제프: 내가 무슨 말을 하려는지 깊이 생각해보지 못했지만 아마도 당신은 일종의 가짜 토큰을 가지고 놀고 있을 것입니다. 내가 생각하는 것은 단지 가짜 토큰을 사용하는 것만으로도 나중에 실제 가치로 교환할 수 있는 포인트를 얻게 되는 구조를 이야기합니다. 예를 들어, 메인넷에서 이것을 시작했다면 제한적으로 수도꼭지(faucet)을 사용해서 토큰을 얻을 수 있습니다. 그리고 제품을 사용하고, 마음껏 플레이하며 플레이 포인트를 얻고 특정 임계값에 도달하면 어느 시점에서 실제 가치로 교환할 수 있는 상품을 얻는 것입니다. 이제
들어가서 플레이하고 플레이 포인트를 얻고 특정 임계값에 도달하면 어느 시점에서 실제 가치로 교환할 수 있는 상품을 얻습니다. 이런 방식은 이러한 플레이를 하고 싶어하지 않는  Defi degen을 끌어들이지 않을 것이라 생각합니다. 충분히 사람들을 끌어들인다면 좋은 피드백을 얻을 수 있을 것입니다. 그렇기 때문에 해결할 수 있는 문제라고 생각합니다.

로버트: 내 생각엔 이런게 실행 가능하다면 약간의 우려가 됩니다. 사용하는 것만으로도 실제 가치가 있는 토큰이 있다면 어떻게든 그 사용을 위조할 수 있을 것입니다.

Alejo: 누군가 스팸 공격을 위해 Aptos 토큰이 필요한 경우 최소한 Aptos 토큰이 필요하기 때문에 가치를 연결하기 시작했다는 것을 알 수 있습니다. 내가 봇이고 이 코인을 얻는 데 1,000달러를 썼다면 이 물건은 1,000달러의 가치가 있습니다. 다시, 당신은 이것을 세상에 출시하고 어떤 일이 일어나는지 보고 그것을 테스트하면서 버그 및 취약점에 대한 현상금에 연결해야 한다고 생각합니다.

로버트: 나의 또 다른 주요 관심사는 대부분 버그는 극단적인 경우이므로 의도적으로 코드를 읽지 않는 한 버그를 찾기가 매우 어렵다는 것입니다. 때로는 UI를 통해 찾지 못할 수도 있습니다. 가끔은 UI를 사용하는 것이 안전할 수도 있지만 UI를 약간 수정하거나 사용자 정의 계약을 호출하게 된다면 악용될 수 있습니다.

Alejo:실제 환경과 다른 곳에서 실행하지 않고 어떻게 메인넷에서 발생하는 문제를 테스트할까요? 실제로 프로덕션 버전이 아닌 프로덕션에서 라이브로 테스트할 수 있는 방법이 있을지도 모릅니다. 이것을 안전하게 할 수 있는 방법이 있습니까?

로버트: 예, 아마도 경제적인 디자인이나 인센티브 모델의 경우에는 더 합리적일 것입니다. 비전문가도 참여해서 내부 문제를 찾을 수 있기 때문입니다.

Alejo: 전문가도 참여할 수 있겠죠? 로버트와 해킹할 수 있는 모든 사람들을 초대하고 싶습니다. 그렇게 하면 결국 현상금이나 화이트 해커 보상이 있어야겠네요. 만약 제품을 부수면, 이것 또한 가격이 생긴다고 제프가 그런 말을 한 것 같아요. 좋은 생각이라고 생각합니다.

로버트: 네, 그것도 효과적일 것 같네요.

Alejo: 마무리할 시간이 되어서 다른 손님 Rasheed을 데려오겠습니다. 그의 질문은 실제 세계(메인넷)에서 발견된 취약점이 있으면 이 프로세스는 어떻게 생겼습니까?

나는 모든 것이 보고서에 나올 것이라고 생각하며, 문제가 있으면 로버트와 긴밀히 협력하여 즉각적으로 수정할 것입니다. 그리고 누구나 읽을 수 있도록 공개보고서를 발간하여 안심하고 제품을 사용할 수 있도록 할 것입니다. 또한 여러 감사원들이 병행해서 감사를 진행하고 있습니다. 로버트에게는 불편하게 들릴 수 있으나 병행해서 여러번 감사를 하는 것이 좋다는 데 그도 동의할 것입니다.

또한 우리가 논의한 것처럼 지갑에 대한 많은 침투 테스트를 수행할 것입니다. 곧 Aptos가 출시되면 메인넷에서 제품을 사용할 수 있습니다. 지금은 모든 것이 devnet에 라이브되어 있는 것입니다. liquidswap.com을 확인하고 테스트해주시면 감사드리겠습니다!

로버트! 커뮤니티가 보안과 어떻게 연결될 수 있는지에 대한 당신의 생각이 궁금합니다.

로버트 : 우리 모두는 사용자에게 서비스를 제공하고 모든 사람들에게 더 나은 제품을 제공하기 위해 최선을 다하고 있기 때문에 사용자를 유지하고 끈끈하게 만드는게 중요하다고 생각합니다. 지갑의 경우에 기본적으로 사용자 랜딩 페이지에서 수익이 발생합니다. 그렇기 때문에 메타마스크는 상대적으로 높은 수수료를 부과하지만 많은 돈을 벌 수 있습니다. 보안을 위해서 우리는 커뮤니티와 직접적인 협력을 하지는 않지만 커뮤니티에 많은 관심을 기울이는 프로토콜로 작업하고 가능한 커뮤니티에서 활동하려고 노력합니다. 사용자로부터 피드백을 듣고 사용자에게 잘 대응할 수 있는 방법을 찾고 이해하는게 좋다고 생각합니다.

Alejo: 네. 그리고 우리가 안전하다고 느끼면 사람들이 계속 머물고 싶어할 것이라고 생각합니다. 그것이 아마도 최우선 순위 일 것입니다. 그렇죠? 사람들이 안심할 수 있도록 말이죠.

로버트: 맞습니다. 최근 모든 보안 문제로 인해 암호화폐에 부정적인 관심이 많은 것 같습니다. 우리가 작업하는 프로토콜이 보안 문제가 없길 바라며 우리는 그것을 목표로 합니다. 이곳에 저를 참여시켜주셔서 감사합니다. 많은 분들과 함께해서 즐거웠습니다! 감사합니다!

Alejo: 와주셔서 감사합니다. 곧 다시 연락드리겠습니다. 앞으로 더 많은 손님을 모실 예정입니다. 질문해 주신 모든 분들께 감사드리며 다음 주에 뵙겠습니다.