그 이상을 구축하세요: 네트워크 확장

저희는 미스텐 랩스의 공동 설립자이자 수석 과학자( Sui)이자 유니버시티 칼리지 런던의 보안 및 개인정보 보호 공학 교수인 조지 다네지스(George Danezis)와 함께 Sui 의 트랜잭션 처리 시스템이 어떻게 고성능 네트워크에 기여하는지 살펴보기로 했습니다.

학자 출신이시군요. 연구의 초점은 무엇이었나요?

저는 유니버시티 칼리지 런던(UCL)의 교수이며, 제 연구의 초점은 크게 보안과 프라이버시입니다. 하지만 2000년대 초반에는 P2P 시스템과 익명성 시스템에 대해 꽤 많은 연구를 했습니다. 이러한 시스템 중 상당수는 스토리지에 중점을 둔 대규모 분산 시스템이었죠. 이더리움으로 블록체인이 실행에 더 집중하게 되면서 분산 원장과 블록체인, 스마트 컨트랙트를 실행하는 방법에 관심을 갖게 되었습니다. 비허가형 측면은 P2P 시스템에 대한 초기 작업에서 꽤 익숙했습니다. 당시 UCL의 연구 그룹과 저는 더 높은 성능의 시스템을 만드는 방법을 모색하기 시작했습니다. 저희는 몇 가지 아이디어를 상용화하기 위해 체인스페이스라는 회사를 설립했습니다. 이 팀은 Facebook에 인수되었습니다. 이후 Facebook 블록체인인 Libra/Diem을 확장할 수 있는 솔루션을 개발하는 데 도움을 주었습니다. 하지만 별다른 진전이 없자 저는 고성능 블록체인이라는 아이디어를 실현할 다른 기회를 찾아 떠났습니다.

여전히 교수로 재직 중이시죠? 연구 분야와 응용 분야 업무의 차이점은 무엇인가요?

사실 큰 차이는 없습니다. 저희는 연구를 할 때 고성능 체인이나 특정 기능 등 특정 작업을 수행하기 위해 필요한 모든 가능성을 고려합니다. 그러나 물론 블록체인을 구축하는 데 기여하거나 실제 시스템에 넣을 특정 기능을 선택할 때는 한 가지 옵션을 선택해야 합니다. 수많은 훌륭한 아이디어 중에서 어떤 것이 실제로 사람들에게 가장 유용할지 항상 판단해야 합니다. 사람들이 요구하는 것은 무엇일까요? 블록체인 도입의 걸림돌은 무엇이며, 사람들이 원하는 것을 하지 못하게 하는 장애물은 무엇일까요? 시스템을 구축할 때는 여전히 모든 가능성을 살펴보고 학술 문헌을 통해 무엇이 가능한지 이해하려고 노력하지만, 가장 관련성이 높은 것을 선택해야 합니다. 이제 더 이상 지적 관심사가 아니라 사용자를 위한 가치를 고려해야 합니다.

이론에서 응용으로 전환할 때 어떤 문제를 해결해야 하는지 어떻게 결정하나요?

제가 연구를 통해 해결한 주요 문제는 블록체인의 다양한 측면을 확장하는 방법이었습니다. 트랜잭션을 늘리고 지연 시간을 줄이는 방법이죠. 저는 블록체인의 시스템 측면을 깊이 연구했습니다. 이더리움의 컨트랙트가 인기를 끌 때마다 이더리움 플랫폼이 그 양을 감당할 수 없다는 문제가 자명하게 드러났죠. 용량이 부족해지고 수수료가 치솟았습니다. 블록체인의 성공 사례가 나올 때마다 저희는 사용 가능한 용량보다 더 많은 용량이 필요하다는 것을 알았습니다. 그래서 사람들이 블록체인에서 하고 싶은 일을 할 수 있는 용량이 충분하지 않다는 것이 문제라는 것을 알았습니다. 이 문제는 그냥 머릿속에서 떠오른 것이 아니라 계속해서 반복해서 발생했습니다. 저희 팀뿐만 아니라 블록체인을 바라보는 학계 전체가 한동안 이 문제를 가치 있는 도전으로 여겼습니다. 요즘에는 블록체인을 확장할 수 있는 기술이 많이 개발되었기 때문에 당연히 다른 도전 과제를 살펴볼 수 있습니다. 하지만 당시에는 많은 사람들이 다양한 방식으로 연구하고 있는 잘 알려진 문제였습니다.

L2는 이러한 확장성 문제에 대해 사람들이 내놓은 하나의 해답입니다. Sui 과 같은 새로운 L1을 구축하면 어떤 차이점이 있으며 어떤 이점이 있을까요?

L2는 이더리움 생태계에서 확장을 위한 솔루션입니다. 그러나 L2는 애플리케이션 개발자가 사용하기에는 다소 어색합니다. L2가 이더리움과 상호작용을 시도할 때, 모든 L2/L1 관계에 해당하지만, 반드시 거쳐야 하는 브리징 활동이 있습니다. 코인이나 자산 등을 나타내는 L1의 상태를 L2에 미러링해야 하며, 그 반대의 경우도 마찬가지입니다. 물론 L1에서 일어나는 모든 일을 L2에서 확인할 수 있도록 L2에는 어떤 메커니즘이 있어야 합니다. 하지만 첫 번째 부분, 즉 L1에 있는 자산을 L2로 전송해야 한다는 것만 하더라도 L2에서 어떤 일이 발생해야 하고, 그 다음에는 어떻게든 자산을 다시 전송해야 합니다. 정말 어색하죠.

이러한 연결 활동은 토큰이나 대체 가능한 자산의 경우 사람들이 두 개의 계정과 그 사이에 브릿지를 가지고 있기 때문에 잘 작동합니다. 하지만 보다 일반적인 자산의 경우, 이는 잘 작동하지 않습니다. 실제로 이더리움에서 L2를 사용해 토큰보다 더 복잡한 애플리케이션을 개발하려면 양쪽 모두에 컨트랙트가 있어야 합니다. 한 계약은 발행되어야 하고 다른 계약은 소각되어야 합니다. 서로 다른 두 생태계에 걸쳐 있다는 사실을 알아야 합니다. 이는 각 컨트랙트에 대한 맞춤형 활동입니다. L2를 만들어서 모든 자산을 가져가서 내가 원하는 대로 하고 다시 가져올 거라고 쉽게 말할 수는 없습니다. 그런 개념은 없습니다. 매우 수동적인 프로세스이며 오류가 발생하기 쉽습니다. 따라서 좋은 경험이 아닙니다. 여러 L2에 걸쳐 자산이 있고 여러 L2에 걸쳐 사용자 지정 컨트랙트가 있다고 상상해 보세요. 다른 L2에 있는 다른 스테이트에 대해 무언가를 하려면 매번 L1으로 다시 연결한 다음 다시 L2로 연결해야 합니다. 방금 이 블록체인에서 무언가를 했으니 이제 다른 블록체인을 통해 다른 작업을 하겠다고 쉽게 말할 수 없습니다. 어떤 L1 또는 L2에 있는지 생각할 필요가 없습니다. 모든 것이 여기에 있습니다. 지금 바로 손에 쥐고 있고, 제가 원하는 상태에서 더 많은 트랜잭션을 처리할 준비가 되어 있습니다. 그렇기 때문에 해당 상태를 여러 L2로 분할하는 것은 좋은 경험이 아닙니다. 에셋을 이동하는 것은 매우 어색하고 사용자에게 눈에 잘 띄기 때문입니다. 이것이 바로 L2가 제 상상력을 사로잡지 못한 이유입니다.

또 다른 예로, 매우 흥미로운 생태계를 가진 코스모스는 확장성을 위해 앱마다 다른 블록체인을 사용한다는 또 다른 접근 방식을 취합니다. 그리고 기본적으로 서로 다른 체인에서 서로 다른 트랜잭션 속도를 가질 수 있으며, 여러 앱에서 작업을 수행해야 할 때 한 체인에서 다른 체인으로 자산을 연결할 수 있습니다. 하지만 동일한 문제가 있습니다. 다른 앱을 사용하려면 매번 먼저 브릿징 작업을 거쳐야 하는데, 이 작업은 사용자에게 매우 섬세하고 눈에 잘 띄는 작업입니다. 그런 다음 앱을 사용하고 다시 브리징할 수 있습니다. 실제로 하고 싶은 일을 하는 것보다 한 체인에서 다른 체인으로 자산을 이동하는 데 더 많은 시간을 소비하게 됩니다.

Sui 에서는 유효성 검사기 간에 복제되는 모든 상태를 포함하는 하나의 큰 데이터베이스가 있는 것을 볼 수 있습니다. 한 트랜잭션이 끝나면 다음 트랜잭션을 수행하기 위해 동일한 데이터베이스에서 모든 것을 사용할 수 있으므로 사용자가 계속 이동하면서 복잡하게 처리할 필요가 없습니다.

Sui 루트리스는 Sui프로토콜의 기반입니다. Sui 가 높은 처리량과 짧은 지연 시간으로 작동할 수 있도록 하는 주요 혁신은 무엇인가요?

Sui 루트리스는 두 가지 핵심 아이디어로 구성되어 있습니다: (1) 블록체인의 많은 작업에서 실제로 합의를 수행할 필요가 없다는 것과 (2) 합의를 수행해야 하는 경우 처리량이 매우 높은 방법이 있다는 것입니다. 루트리스는 이 두 가지 접근 방식을 취하고 결합합니다. Sui 루트리스는 Sui분산 네트워크에서 트랜잭션을 수행할 때 프로토콜을 따르는 두 개의 서로 다른 검증자가 일관되지 않은 상태에 있지 않도록 보장하는 분산 시스템의 핵심입니다. 한 검증자는 사용자가 코인을 사용해 앨리스에게 보냈다고 판단하고 다른 검증자는 같은 코인이 실제로 밥에게 갔다고 판단하는 일은 절대 일어나지 않습니다.

합의가 필요하지 않은 경로와 합의가 필요한 경로에는 두 가지가 있습니다. 예를 들어 나만의 NFT 캐릭터와 캐릭터가 모자를 쓸 수 있도록 결합하려는 모자와 같이 나만 소유한 오브젝트를 작업하려는 경우 이론적으로 다른 사람이 작업해서는 안 됩니다. 이러한 경우 Sui 에서 빠른 경로를 사용합니다. 자신의 객체에 대해 작업할 수 있다고 말합니다. 합의를 기다릴 필요 없이 이 트랜잭션에 대한 최종성을 얻고, 트랜잭션이 발생했는지 확인하고, 캐릭터에 모자를 씌울 수 있습니다.

하지만 어떤 경우에는 거래에 나만의 것이 아닌 물건이 포함되기도 합니다. 많은 사람이 공유하는 물건이죠. 예를 들어, 캐릭터용 작은 모자를 판매하는 경매가 있는 경우 이러한 종류의 경매는 Sui 에서 공유 개체로 표시됩니다. 사람들은 입찰을 할 수 있고 가장 높은 입찰가를 제시한 사람이 모자를 낙찰받습니다. 경매는 한 개체가 소유하지 않는 일종의 물건입니다. 모든 사람이 입찰을 하고, 공유하고, 최신 입찰에 대한 상태를 업데이트할 수 있어야 합니다. 이러한 작업에는 추가적인 합의가 필요합니다. Sui 루트리스를 사용하면 공유 오브젝트를 갖고 그 오브젝트에서 자신이 소유한 다른 오브젝트로 연결되는 트랜잭션을 수행하거나, 공유 오브젝트의 상태를 변경하거나, 새로운 공유 오브젝트를 생성할 수 있습니다. 두 가지 경로가 공존할 수 있으며, 특정 개인이 소유한 오브젝트나 공유된 오브젝트가 서로 상호작용을 할 수 있습니다.

이 두 가지 경로는 서로 다른 강점을 가지고 있습니다. 소유 오브젝트 경로는 지연 시간이 매우 짧고 매우 광범위하게 확장할 수 있습니다. 합의 경로는 지연 시간이 더 깁니다. 따라서 첫 번째 경로는 1초도 채 걸리지 않고 매우 빠릅니다. 공유 오브젝트에 대한 합의 경로는 1초 이상이며 용량도 상당히 큽니다. 하지만 첫 번째 경로보다 확장하기가 더 어렵습니다. Sui 에서 하루에 수백만 건의 트랜잭션으로 체인을 마비시키는 애플리케이션은 보통 첫 번째 경로를 사용하며, 대부분 공유가 아닌 소유 오브젝트에 대한 트랜잭션 수가 가장 많도록 애플리케이션을 구성합니다. 반면에 탈중앙 금융과 같이 복잡한 작업을 수행하는 프로토콜은 작업을 수행하기 위해 많은 사람들의 입찰이나 유동성을 결합해야 하기 때문에 보통 두 번째 유형의 트랜잭션을 사용합니다.

Sui 에서 앱 개발자가 빠른 경로를 활용하도록 앱을 설계할 수 있나요?

네, 물론이죠. 이것이 바로 확장이 필요한 앱 디자이너의 핵심 업무라고 생각합니다. 스마트 컨트랙트 개발자는 컨트랙트에서 조작하는 객체가 특정 시점에 단일 엔티티가 소유하는 객체인지, 아니면 공유 객체인지에 대한 모든 권한을 가지고 있습니다. Sui 에서 애플리케이션을 확장하는 요령은 Sui 에서 기본적으로 매우 짧은 지연 시간으로 원하는 만큼의 개체를 관리할 수 있으므로 가장 많은 작업이 단일 소유자 개체에 주로 이루어지도록 하는 것입니다. 정말 좋은 경험입니다. 게임에 필요한 액션은 지연 시간이 매우 짧기 때문에 해당 카테고리에 속해야 합니다. 클릭하는 즉시 트랜잭션이 네트워크에서 완료됩니다. 공유 상태와 공유 오브젝트를 통해 중개되어야 하는 액션과는 대조적입니다.

스마트 콘트랙트 설계자는 이를 완전히 제어할 수 있습니다. 기본적으로 어떤 트랜잭션이 각 카테고리에 속하는지 정확히 지정할 수 있습니다. 물론 첫 번째 버전의 컨트랙트에서는 모든 것을 공유 상태로 두고 모든 것이 지연 시간이 긴 합의 경로를 거칠 수 있지만, 확장할 필요가 생기면 개발자는 이러한 부분이 필요하지 않도록 얼마나 할 수 있을지 고민해야 합니다.

프로그래머블 트랜잭션 블록은 여기에 어떻게 적용되나요?

프로그래머블 트랜잭션 블록은 빠른 경로 또는 합의 경로에 있을 수 있습니다. 프로그래머블 트랜잭션 블록이 자신의 오브젝트에만 영향을 미친다면, 이는 한 번에 많은 작업을 온체인 상에서 수행할 수 있다는 뜻입니다. 예를 들어보겠습니다. 중앙화된 거래소에서 많은 사람이 서로 다른 코인을 사고 팔았다고 가정해봅시다. 사람들이 사고 판 것에 개념적으로 해당하는 객체로 온체인에서 하나의 트랜잭션을 수행할 수 있지만, 거래소이기 때문에 모든 객체가 여러분의 소유이며 수천 개의 객체가 동시에 결제될 수 있습니다. 이것이 빠른 경로입니다. 반면, 프로그래밍 가능한 트랜잭션 블록 내에서 일부 객체가 공유되는 경우, 이는 합의 경로로 이동하며 지연 시간이 1초 미만이 아닌 몇 초로 조금 더 길어집니다.

메인넷은 약 100일 전에 출시되었습니다. Sui 에서 연구를 통해 이론적 가설을 확인한 것은 무엇인가요? 어떤 점이 놀라웠나요?

Sui의 디자인이 여러 가지로 확인되었지만, 몇 가지 점에서 생각해 볼 점이 있습니다. 한 가지 확실한 점은 특별 프로모션이 있는 날에는 하루에 6천만 건 이상의 트랜잭션이 발생하더라도 대부분의 트랜잭션이 실제로 빠른 경로에 있었다는 점입니다. 확장성이 뛰어나고 지연 시간이 매우 짧은 Sui 루트리스의 경로입니다. 그 전까지는 아무도 이 경로를 사용할지 확신할 수 없었지만, 대량 거래와 짧은 지연 시간이 필요할 때 이 경로가 사용되었습니다. 그리고 작동합니다! 정말 다행입니다. 그리고 이것이 바로 그 방법입니다. 그 당시 Sui 에서 다른 모든 블록체인을 합친 것보다 더 많은 트랜잭션이 발생했습니다. 이는 Sui의 설계가 합리적이라는 것을 보여주는 흥미로운 증거입니다.

동시에 Sui 커뮤니티에서는 이 빠른 경로가 약간 미묘하다는 사실을 발견했습니다. 객체의 소유자가 어느 정도는 자신의 객체에 대한 작업 순서를 관리해야 하기 때문에 때때로 잘못될 수 있습니다. 때로는 도움이 되지 않는 라이브러리를 사용할 수도 있고, 라이브러리 자체가 잘못되어 객체가 잠기는 경우도 있습니다. 보통은 하루가 끝날 때, 시대가 끝날 때 잠금이 해제됩니다. 하지만 이는 좋은 경험이 아닙니다. 스마트 컨트랙트를 설계하는 사람들은 실수로 이런 일이 발생할 수 있다는 점을 매우 두려워하며, 이로 인해 지연 시간이 짧고 확장성이 뛰어난 기능을 최대한 활용하지 못합니다. 실수로 개체를 잠근 사람들이 몇 초 안에 매우 빠르게 잠금을 해제할 수 있도록 하는 다양한 기술이 개발되고 있습니다. 따라서 빠른 경로를 사용하려다가 실수로 개체가 잠긴 경우, 하루가 끝날 때까지 기다릴 필요 없이 즉시 합의 경로를 사용하여 잠금을 해제할 수 있습니다.

그리고 이상하게도 이는 실수를 피하는 것만이 아닙니다. 또한 개발자는 빠른 경로를 통해 더 많은 것을 표현할 수 있습니다. 일부 객체는 한 당사자만 소유하지 않는 잠재적인 기술이 있습니다. 여러분과 제가 함께 소유하는 객체가 있을 수 있습니다. 기존에는 해당 객체가 공유되어 있기 때문에 해당 객체에 대한 트랜잭션은 합의 경로를 거쳐야 했습니다. 하지만 Sui 에 객체의 잠금을 해제하는 빠른 방법이 있다면, 개발자는 실제로 빠른 경로를 통해 트랜잭션을 처리하려고 낙관적으로 시도할 수 있습니다. 만약 여러분과 제가 같은 오브젝트에 대해 정확히 동시에 트랜잭션을 생성하고 시스템이 다음에 어떤 트랜잭션이 발생할지 결정하지 못해 잠기는 경우, Sui 에서 잠금을 해제하고 합의 경로를 거쳐 공유하여 해결하도록 할 수 있습니다. 하지만 사람들이 일부러 서로 경쟁하려는 것이 아니라면 이런 상황이 발생할 가능성은 매우 낮습니다. Sui 에 객체의 잠금을 해제할 수 있는 기능이 추가되면 여러 사람이 소유한 객체가 빠른 경로를 통과할 수 있게 될 것입니다. 빠른 경로를 통해 최대한 많은 물량을 넣으려는 게임이며, 빌더 커뮤니티를 돕기 위해 개발 중인 기능입니다.

현재 오브젝트가 잠기는 원인을 더 자세히 공유해 주시겠어요?

어떤 객체가 사용자 소유인 경우, 합의를 거쳐 Sui 어떤 작업 순서가 발생하는지 알릴 필요가 없는 이유는 객체에 대해 작업할 수 있는 다른 사람이 없기 때문입니다. Sui 작업 A가 먼저 발생하고, 작업 B가 두 번째로 발생하며, 작업 C가 세 번째로 발생한다고 시스템에 알려주는 것은 사용자에 의존합니다. 시스템은 여전히 모든 사람이 동일한 순서로 A, B, C를 볼 수 있는지 확인해야 합니다. 문제는 사용자가 실수하거나 소프트웨어가 실수를 하는 경우입니다. 이 시스템은 분산 프로토콜을 통해 모든 사람이 A, B, C를 보았는지 확인합니다. 예를 들어, 자산을 제어하는 휴대폰과 자산을 제어하는 컴퓨터가 있는데 휴대폰은 첫 번째 작업이 A라고 말하고 컴퓨터는 첫 번째 작업이 B라고 말하는 경우, 실수로 두 가지 다른 작업이 먼저 일어나도록 순서를 지정한 것입니다. 모순이 발생합니다. 이 경우 Sui 에 "순서를 알려달라고 부탁한 사람이 모순되는 두 가지를 알려준 것 같아서 어떻게 해야 할지 모르겠어요. 이 문제를 어떻게 해결해야 할지 모르겠습니다. Sui 의 일반적인 해결 방법은 합의 경로를 통해 해결하는 것이기 때문입니다. 하지만 여기서는 빠른 경로를 사용하려고 합니다. Sui 이 손을 들어 "여기 실수가 있었어요"라고 말합니다.

원래는 이런 상황이 극히 드물 것이라고 가정했지만, 사람들이 서로 다른 기기를 사용하거나 동일한 객체에 대해 동시에 여러 트랜잭션을 수행하려고 시도하기 때문에 이런 일이 발생합니다. 실제로 이런 일이 꽤 자주 발생한다는 것이 밝혀졌습니다. 현재 이러한 오브젝트가 잠기면 Sui 은 해당 시대가 끝날 때까지 기다렸다가 잠금을 해제합니다. 이것은 정말 걱정스러운 일입니다. 자산을 하루 동안 사용할 수 없다고 상상해 보세요. 실제로 심각한 문제가 될 수 있습니다.

이제 Sui 는 무언가가 잠겼을 때 올바른 일을 하도록 진화해야 합니다. 정확한 시퀀스를 제공하도록 위임받은 주체가 모호한 시퀀스를 제공한 경우 Sui 이 전체 상황을 취합하여 합의를 통해 문제를 해결합니다. 그리고 이 과정은 하루가 끝나는 시점이 아니라 몇 초 내에 이루어집니다.

많은 연구가 프라이버시에 관한 것이었습니다. 퍼블릭 블록체인이 투명성 및 추적성과 프라이버시 사이의 균형을 가장 잘 맞출 수 있는 방법에 대해 어떻게 생각하시나요?

개인 정보 보호와 블록체인에 대한 제 생각은 무엇이 비공개로 유지되어야 하는지는 애플리케이션에 따라 매우 다르다는 것입니다. 예를 들어, Sui 에서는 앱 개발자가 사용자의 개인 정보 보호와 관련하여 적절한 보호 기능을 제공하는 계약을 개발할 수 있습니다. 어떤 사람들은 게임 개발만 원하기 때문에 개인정보 보호에 대한 우려가 그다지 크지 않을 수도 있습니다. 어떤 사람들은 개인 정보 보호가 더 중요할 수 있는 금융 문제에 블록체인을 사용하고자 하지만, 규제와 관련된 다른 종류의 우려도 있습니다. 그래서 Sui 에서는 훌륭한 플랫폼을 제공할 테니 그 플랫폼 위에 프라이버시를 구축하면 된다고 말합니다.

사람들이 프라이버시를 구축할 수 있도록 Sui 에서는 스마트 컨트랙트를 설계할 때 유용하게 사용할 수 있는 몇 가지 암호화 기본 요소를 제공합니다. 그중 가장 중요한 것은 Sui 에서 영지식 증명을 검증할 수 있는 기능입니다. 가장 널리 사용되고 이해되는 체계 중 하나인 제 동료 Jens Groth가 개발한 Groth16 체계의 검증을 수행하는 기본 함수가 있습니다. 즉, 사실상 앱 디자이너는 어떤 일이 체인 외부에서 발생했는지 밝히지 않고도 그 증명을 사용할 수 있습니다. 이는 오프체인에서는 일부 상태를 유지하지만 온체인에서는 오프체인에서 일어난 일이 올바른지 확인할 수 있는, 프라이버시 친화적인 앱의 전체 범주를 구축하기 위한 기본 구성 요소입니다.

앱 개발자는 앱에 어떤 종류의 프라이버시가 필요한지 결정하고 기본 요소를 사용하여 온체인, 오프체인, 암호화된 온체인 등 프라이버시 문제를 처리하는 데 필요한 전략을 조합할 수 있습니다.

Sui 에 더 많은 개인정보 보호 기본 사항이 있나요?

커뮤니티는 개발자가 보다 프라이버시 친화적인 방식으로 스마트 컨트랙트를 작성하는 데 필요한 기본 요소에 대해 고민하고 있습니다. 영지식 증명은 그중 하나입니다. 어떤 사람들은 Sui 온체인에 더 일반적인 수학이나 암호화 함수가 필요하다고 주장할 수 있습니다. 스마트 콘트랙트 설계자들이 부족한 부분에 대한 피드백을 제공해 주시면 좋겠습니다. 다자간 연산이나 신뢰할 수 있는 하드웨어와 같이 프라이버시를 보호하기 위해 사용할 수 있는 다른 기술들이 많이 있습니다. 다양한 체인이 이러한 방향으로 나아가고 있습니다. 이러한 기술에는 매우 복잡한 추가 시스템이 필요합니다. 이러한 기술은 Sui 아키텍처의 근본적인 변화를 의미하기 때문에 커뮤니티에서 사람들이 이러한 기술을 원한다는 충분한 증거가 있어야 합니다. 하지만 커뮤니티가 이러한 방향으로 나아가고자 한다면, 프라이버시를 보호하는 방법에 대한 추가 사항을 제안하는 절차가 있습니다.

향후 6~12개월 내에 Sui 가 어떻게 발전할 것으로 예상하시나요?

사람들이 Sui 에서 어떤 종류의 앱을 개발하는지에 따라 달라집니다. 단기적으로는 사람들이 실제로 개발하는 앱에 초점을 맞춰 많은 개선이 이루어질 것입니다. 장기적으로는 블록체인 기준으로는 매우 긴 6~12개월 정도에 걸쳐 Sui 루트리스 프로토콜을 개선하여 지연 시간을 더욱 낮추고, 더 단순화하여 Sui 을 더 잘 확장할 수 있도록 개선하는 작업이 진행 중입니다. 그리고 검증자가 더 제한된 하드웨어에서 실행될 수 있도록 경제성을 높이고, 암호화나 블록체인의 다른 모든 오버헤드를 수행하는 대신 실제로 트랜잭션을 실행하는 데 필요한 하드웨어를 사용할 수 있도록 하는 것이 목표입니다. 이것이 바로 제가 기대하는 것입니다.