심층 대화: 하위에서 보는 Sui 디자인 개념 및 네트워크 규모 확장

저자: Sui Network

최근에 우리는 George Danezis와 인터뷰를 진행하여 Sui 인프라의 복잡성과 확장성, 그리고 Sui의 거래 처리 시스템이 어떻게 고성능 네트워크를 가능하게 하는지에 대해 논의했습니다. George Danezis는 Mysten Labs의 공동 창립자이자 수석 과학자( Sui의 초기 기여자)이며, 런던 대학교의 안전 및 프라이버시 공학 분야 교수입니다.

다음은 이번 인터뷰 내용입니다: Q1 당신은 학계 출신인데, 연구의 초점에 대해 소개해 주시겠습니까?

저는 런던 대학교(University College London, UCL)의 교수로, 연구의 초점은 넓게 말해 안전과 프라이버시입니다. 20세기 초반에 저는 P2P 시스템과 익명 시스템에 대해 상당한 연구를 진행했으며, 이러한 시스템은 대부분 저장 중심의 대규모 분산 시스템이었습니다. 블록체인이 실행에 더 중점을 두게 되었고, 특히 이더리움을 대표로 하여, 저는 분산 원장과 블록체인, 그리고 스마트 계약을 실행하는 방법에 관심을 가지게 되었습니다. 그 중에서도 허가 없는 특성은 제가 초기 P2P 시스템 작업에서 매우 익숙한 부분입니다. 그래서 저는 UCL의 연구 그룹에서 더 높은 성능의 시스템을 구축하는 방법을 연구하기 시작했습니다. 우리는 Chainspace라는 회사를 설립하여 우리의 아이디어를 상용화했으며, 이후 팀은 Facebook에 인수되었습니다. 그 후 우리는 Facebook이 블록체인 Libra/Diem을 확장하는 솔루션을 제안하는 데 도움을 주었습니다. 그러나 솔루션이 진전을 보이지 않자 저는 떠나 다른 기회를 찾아 고성능 블록체인 아이디어를 실현하고자 했습니다. Q2 당신은 여전히 교수인데, 응용과 연구 사이에는 어떤 차이가 있다고 생각하십니까?

실제로 큰 차이는 없습니다. 우리가 연구를 진행할 때, 우리는 특정 목표를 달성하기 위한 모든 가능성을 고려합니다. 예를 들어, 고성능 블록체인이나 특정 기능을 구축하는 것입니다. 물론 블록체인을 구축하거나 실제 시스템에서 사용할 특정 기능을 선택할 때, 우리는 여러 가능성 중 하나를 선택해야 합니다. 우리는 지속적으로 판단을 내려야 합니다. 이러한 좋은 아이디어 중에서 어떤 것이 실제로 사람들에게 가장 유용한가? 사람들이 찾고 있는 것은 무엇인가? 블록체인의 채택에는 어떤 병목 현상이 존재하는가? 무엇이 사람들이 원하는 것을 실현하는 것을 방해하는가? 시스템을 구축할 때, 여전히 모든 가능성을 고려하고 학술 문헌에서 가능한 상황을 이해하려고 노력한 후 가장 관련성이 높은 내용을 선택합니다. 이것은 단순한 지식의 관심이 아니라 사용자에게 가치를 창출하는 것입니다. Q3 이론에서 실제 응용으로 넘어갈 때, 어떤 문제를 해결해야 할지를 어떻게 결정하십니까?

제가 연구에서 해결하는 주요 문제는 블록체인의 다양한 기능을 확장하는 방법입니다. 저는 블록체인의 시스템 측면에 집중하고 있습니다. 예를 들어, 거래 처리량을 증가시키고 지연 시간을 줄이는 방법입니다. 이 문제는 명백합니다. 이더리움에서 어떤 계약이 매우 인기를 끌 때마다, 이더리움 플랫폼은 그렇게 많은 거래량을 감당할 수 없고 거래가 혼잡해지며 수수료가 폭등합니다. 블록체인이 성공할 때마다 우리는 그것이 처리할 수 있는 거래량이 기존의 능력을 초과하는 것을 봅니다. 따라서 문제는 사람들이 이러한 블록체인에서 하고자 하는 일을 충족할 수 있는 충분한 능력이 없다는 것입니다. 이는 우리의 생각에서 비롯된 것이 아니라, 우리는 이 상황이 반복적으로 발생하는 것을 보았습니다. 한동안 이것은 가치 있는 도전으로 여겨졌고, 제 팀뿐만 아니라 사실상 전체 학계가 블록체인 연구에 몰두하며 다양한 방식으로 이 문제를 해결하고 있습니다. 현재 블록체인의 능력을 확장하기 위해 상당히 많은 기술이 개발되었습니다. 하지만 그 당시에는 많은 사람들이 다양한 방식으로 이를 해결하려고 했다는 것이 잘 알려져 있습니다. Q4 L2 네트워크는 사람들이 확장 문제를 해결하기 위해 제안한 방법 중 하나인데, Sui와 같은 새로운 L1 네트워크를 구축하는 것과 어떤 차이점과 장점이 있습니까?

L2는 이더리움 생태계에서의 확장 솔루션입니다. 그러나 애플리케이션 개발자에게 L2 네트워크를 사용하는 것은 다소 까다롭습니다. L2 네트워크가 이더리움과 상호작용하려고 할 때, 브리징 활동이 필요합니다. 이는 모든 L2/L1 관계에 해당합니다. L1에서 coin, 자산 또는 기타 내용을 나타내는 상태는 L2에서 미러링되어야 하며, 그 반대도 마찬가지입니다. 그 외에도 L2는 L1이 그 안에서 발생하는 모든 것을 검증할 수 있도록 하는 메커니즘이 있어야 합니다. 하지만 이것은 첫 번째 부분일 뿐입니다. 즉, L1에 존재하는 모든 자산은 L2로 이동해야 하며, L2에서 어떤 활동이 발생한 다음, 어떤 방식으로든 자산을 L1으로 다시 가져와야 합니다. 이는 매우 번거롭습니다.

토큰과 같은 대체 가능한 자산의 경우, 이러한 브리징 활동은 비교적 순조롭게 진행됩니다. 왜냐하면 사람들은 두 개의 계정과 브리징 미들웨어를 가지고 있기 때문입니다. 그러나 더 일반적인 자산의 경우, 효과가 좋지 않습니다. 이더리움에서 L2 네트워크를 사용하여 토큰보다 더 복잡한 애플리케이션을 개발하려면, 양쪽에 스마트 계약이 필요합니다. 하나는 민트(mint)용이고, 다른 하나는 번(burn)용입니다. 이들은 두 개의 서로 다른 생태계에서 오가야 하며, 이는 각 계약의 사용자 정의 활동입니다. "나는 L2 네트워크를 만들고 모든 자산을 가져가서 내 마음대로 작업한 다음 다시 가져올 것이다"라는 개념은 없습니다. 이는 수동적인 과정이며, 매우 오류가 발생하기 쉽습니다. 따라서 이는 좋은 경험이 아닙니다. 여러 다른 L2 네트워크에 자산이 있고, 이러한 사용자 정의 스마트 계약이 있는 경우를 상상해 보십시오. 매번 다른 L2 네트워크에 있는 특정 상태를 조작하려고 할 때마다, L1으로 다시 브리징한 다음 L2로 돌아가야 합니다. "나는 이 블록체인에서 방금 어떤 작업을 했고, 이제 다른 블록체인에서 또 다른 작업을 해야 하며, 그것이 어떤 L1 또는 L2인지 고려할 필요가 없다"라고 쉽게 말할 수 없습니다. 모든 것이 여기 있으며, 지금 손에 쥐고 있으며, 내가 접근하고자 하는 어떤 상태에서 더 많은 거래를 할 준비가 되어 있습니다. 이것이 L2 네트워크에 상태를 분산시키는 경험이 좋지 않은 이유입니다. 서로 다른 체인 간에 자산을 이동하는 것은 매우 까다롭고 사용자에게도 명백합니다. 이것이 L2 네트워크가 저에게 실제로 흥미를 끌지 않았던 이유입니다.

또 다른 예는 Cosmos입니다. Cosmos는 서로 다른 앱을 위해 서로 다른 블록체인을 사용하여 확장하는 매우 흥미로운 생태계를 가지고 있습니다. 우리는 서로 다른 체인에서 서로 다른 거래 속도를 가질 수 있으며, 서로 다른 앱 간에 작업을 수행해야 할 때 자산을 체인 간에 브리징할 수 있지만, 동일한 문제에 직면합니다. 서로 다른 앱을 사용할 때마다 먼저 브리징 작업을 수행해야 하며, 이는 사용자에게 미묘하고 명백합니다. 그런 다음 해당 앱을 사용하고 다시 브리징해야 합니다. 당신은 자산을 한 체인에서 다른 체인으로 이동하는 데 더 많은 시간을 소비하게 되고, 당신이 실제로 하고자 하는 일을 하는 데는 시간이 덜 걸립니다.

Sui에서는 우리의 솔루션이 대규모 데이터베이스를 구축하는 것입니다. 실제로, 이는 모든 검증된 노드가 복제한 상태를 포함합니다. 거래를 완료하면, 동일한 데이터베이스에 있는 모든 상태가 다음 거래를 수행하는 데 사용될 수 있으며, 사용자는 L1과 L2 간에 자산 상태를 계속 이동할 필요가 없습니다. Q5 Sui Lutris는 Sui 프로토콜의 기초로, Sui가 높은 처리량과 낮은 지연 시간을 가지게 하는 핵심 혁신은 무엇입니까?

Sui Lutris는 두 가지 핵심 아이디어로 구성됩니다: (1) 블록체인에서 많은 작업에 대해 실제로 합의가 필요하지 않습니다; (2) 실제로 합의가 필요할 때, 매우 높은 처리량의 방법이 있으며, 이 두 가지 방법을 결합합니다. Sui Lutris는 Sui 분산 시스템의 핵심으로, 분산 네트워크에서 거래를 수행할 때 프로토콜을 따르는 두 개의 서로 다른 검증 노드가 결코 불일치 상태에 있지 않도록 보장합니다. 따라서 한 검증 노드는 당신이 하나의 coin을 사용하여 Alice에게 보냈다고 생각하는 반면, 다른 검증 노드는 동일한 coin이 실제로 Bob에게 보내졌다고 생각하는 상황이 발생하지 않습니다.

? Sui Lutris:

https://tech.mystenlabs.com/sui-lutris-the-distributed-system-protocol-at-the-heart-of-sui

두 개의 서로 다른 경로가 있습니다. 하나는 합의가 필요 없는 빠른 경로이고, 다른 하나는 합의가 필요한 합의 경로입니다. 당신이 조작하려는 객체가 오직 당신의 것일 때, 예를 들어 당신의 NFT 캐릭터와 당신이 조합하고 싶은 모자라면, 이론적으로 다른 사람은 그것들을 조작해서는 안 됩니다. 이러한 경우에 Sui는 빠른 경로를 사용합니다. 이는 당신이 자신의 객체를 조작할 수 있으며, 합의를 기다리지 않고 거래의 최종성을 얻을 수 있음을 의미합니다. 거래가 발생하고 모자가 당신의 NFT 머리에 씌워집니다.

하지만 특정 경우에는 거래가 단순히 당신의 객체만 포함되지 않고, 여러 사람이 공유하는 객체가 포함됩니다. 예를 들어, 작은 모자를 판매하는 경매가 있다면, 이러한 유형의 경매는 Sui에서 공유 객체로 표시됩니다. 사람들은 입찰할 수 있으며, 가장 높은 입찰자가 모자를 얻습니다. 이러한 경매는 단일 개체에 속하지 않는 객체로, 모든 사람이 입찰하고 공유하며 최신 입찰 상태를 업데이트할 수 있어야 하며, 이러한 유형의 작업에는 추가적인 합의가 필요합니다. Sui Lutris는 당신이 공유 객체를 소유하고 그 위에서 거래를 수행할 수 있도록 하여, 다른 객체를 소유하거나 공유 객체의 상태를 변경하거나 새로운 공유 객체를 생성할 수 있게 합니다. 이는 두 개의 경로가 공존할 수 있도록 하며, 특정 개인이 소유한 독점 객체와 여러 사람이 공유하는 공유 객체 간의 상호작용을 가능하게 합니다.

이 두 개의 서로 다른 경로는 서로 다른 장점을 가지고 있습니다. 독점 객체의 빠른 경로는 지연 시간이 극히 낮고, 1초도 채 걸리지 않으며, 매우 빠르고 광범위하게 확장 가능합니다. 반면 합의 경로의 지연 시간은 더 높고, 일반적으로 1초를 초과하며, 용량도 상당히 높지만, 첫 번째 경로에 비해 확장하기가 더 어렵습니다. Sui에서는 실제로 매일 수백만 건의 거래를 통해 체인 상의 앱을 추진하는 사람들이 일반적으로 첫 번째 경로를 사용하며, 그들의 앱을 주로 독점 객체에서 가장 많은 거래를 수행하도록 구조화합니다. 반면 복잡한 작업을 수행하는 프로토콜(예: DeFi)은 일반적으로 두 번째 유형의 거래를 수행합니다. 왜냐하면 그들은 여러 사람의 입찰이나 유동성을 결합하여 작업을 수행해야 하기 때문입니다. Q6 Sui의 앱 개발자는 빠른 경로를 활용하여 그들의 앱을 설계할 수 있습니까?

네, 절대 가능합니다. 저는 이것이 앱 설계자에게 확장성을 제공하는 핵심 작업이라고 생각합니다. 스마트 계약 개발자는 그들이 계약에서 조작하는 객체가 특정 시점에 단일 개체의 독점 객체인지 공유 객체인지 완전히 제어할 수 있습니다. Sui에서 앱을 확장하는 한 가지 요령은 대부분의 작업이 기본적으로 독점 객체에서 수행되도록 하는 것입니다. 왜냐하면 Sui는 매우 낮은 지연 시간에서 원하는 많은 작업을 관리할 수 있기 때문입니다. 이는 훌륭한 경험입니다. 게임에 필요한 작업은 이 범주에 포함되어야 하며, 공유 상태와 공유 객체를 통해 조정해야 하는 작업에 비해 지연 시간이 매우 낮습니다. 클릭 한 번으로 거래가 네트워크에서 즉시 완료될 수 있습니다.

스마트 계약 설계자는 이에 대해 완전한 제어권을 가지며, 기본적으로 각 범주에서 거래가 무엇인지 정확하게 지정할 수 있습니다. 물론 계약의 첫 번째 버전은 모든 것을 공유 상태로 간주할 수 있으며, 모든 것이 더 높은 지연의 합의 경로를 통해 진행되지만, 확장이 필요해짐에 따라 개발자는 이러한 부분이 필요하지 않은 정도를 고려해야 합니다. Q7 프로그래머블 거래 블록은 이 과정에서 어떻게 작용합니까?

프로그래머블 거래 블록은 빠른 경로 또는 합의 경로에서 작용할 수 있습니다. 만약 프로그래머블 거래 블록이 오직 당신의 독점 객체만 포함한다면, 이는 당신이 하나의 체인에서 여러 작업을 수행할 수 있음을 의미합니다. 예를 들어, 당신이 CEX 앱이고 많은 사람들이 여기서 다양한 코인을 사고 팔고 있다면, 당신은 체인에서 한 번의 거래를 수행할 수 있으며, 이는 사람들이 사고파는 내용에 해당합니다. 그러나 당신이 거래소이기 때문에, 모든 것이 당신에게 속하므로 동시에 천 개의 거래를 정산할 수 있습니다. 이는 빠른 경로입니다. 반면에, 프로그래머블 거래 블록 내의 일부 객체가 공유되는 경우, 이는 합의 경로로 들어가며, 이때 지연 시간이 조금 더 높아지고, 1초가 아닌 몇 초가 걸립니다. Q8 메인넷이 가동된 지 100일이 넘었는데, Sui의 성능이 당신의 연구 이론을 증명했습니까? 놀라운 점이 있었습니까?

Sui의 설계를 증명하는 몇 가지 사항이 있었지만, 몇 가지는 깊이 생각하게 만들었습니다. 하나는 거래량이 특히 많을 때, 심지어 특정 시점에 하루 거래량이 6000만 건을 초과하는 경우가 있었으며, 그 대부분의 거래는 빠른 경로에서 발생했습니다. Sui Lutris는 매우 확장 가능하며 지연 시간이 매우 낮습니다. 그 이전에는 사람들이 이 경로를 사용할 것인지 불확실했지만, 대량의 거래와 낮은 지연이 필요할 때 사용되었고, 매우 효과적이었습니다! 이는 쉽게 볼 수 있는 방법입니다. 그 날들 동안 Sui의 거래량은 모든 다른 블록체인의 총합을 초과했습니다. 이는 Sui의 설계가 합리적임을 증명하는 흥미로운 검증입니다.

동시에 Sui 커뮤니티는 이 빠른 경로가 다소 미묘하다는 것을 발견했습니다. 객체의 소유자는 어느 정도 자신의 객체에서 작업 순서를 관리해야 하며, 때때로 실수를 할 수 있습니다. 때때로 그들은 심지어 그들을 도와주지 않는 라이브러리를 사용할 수 있으며, 라이브러리 자체가 오류를 발생시켜 객체가 잠길 수 있습니다. 일반적으로 그것들은 하루가 끝날 때, 즉 한 epoch가 끝날 때 잠금 해제되지만, 이는 좋은 경험이 아닙니다. 스마트 계약을 설계하는 사람들은 이러한 상황이 발생할 수 있다는 두려움 때문에 저조한 지연 시간과 확장성의 시설을 충분히 활용하지 못하게 됩니다. 오류로 잠긴 객체를 몇 초 내에 빠르게 잠금 해제할 수 있도록 허용하는 기술 세트가 개발되고 있습니다. 따라서 빠른 경로를 사용하려고 시도할 때 오류가 발생하고 객체가 잠기면, 즉시 합의 경로를 사용하여 잠금을 해제할 수 있습니다. 한 epoch가 끝날 때까지 기다릴 필요가 없습니다.

그리고 이상하게도, 이는 단순히 오류를 피하기 위한 것이 아니라, 개발자가 빠른 경로를 통해 더 많은 것을 표현할 수 있도록 허용합니다. 일부 객체는 단순히 한 당사자가 소유하는 것이 아닙니다. 아마도 당신과 내가 공동으로 소유하는 객체가 있을 수 있습니다. 이는 공유 객체이므로, 일반적으로 해당 객체에서의 거래는 합의 경로를 통해 이루어져야 합니다. 그러나 Sui가 객체를 빠르게 잠금 해제하는 방법을 가지고 있다면, 개발자는 실제로 빠른 경로를 통해 거래를 시도할 수 있습니다. 당신과 내가 같은 시간에 동일한 객체에 대해 거래를 시도하는 경우, 시스템은 잠겨서 어떤 거래가 다음에 발생할지를 결정할 수 없으며, 그런 다음 Sui는 그것을 잠금 해제하고 합의 경로를 통해 공유하게 하여 해결할 수 있습니다. 그러나 사람들이 의도적으로 경쟁하려고 하지 않는 한, 이러한 상황은 발생할 수 없습니다. Sui가 객체를 잠금 해제할 수 있는 기능을 갖추게 되면, 여러 사람이 소유하는 객체가 빠른 경로를 통해 거래될 수 있어야 합니다. 이는 가능한 한 많은 거래량을 빠른 경로를 통해 전달하려는 게임의 일종이며, 이는 구축자 커뮤니티를 돕기 위해 개발되고 있는 것입니다. Q9 현재 객체 잠금의 원인에 대해 더 자세히 공유해 주실 수 있습니까?

당신의 객체가 당신에게 속할 때, 그것이 합의를 통해 Sui에 일련의 작업 순서를 알릴 필요가 없는 이유는 다른 사람이 당신의 객체를 조작할 수 없기 때문입니다. Sui는 당신이 시스템에 A 작업이 먼저 발생하고, B 작업이 그 다음에 발생하며, C 작업이 마지막에 발생한다고 알려주는 것에 의존합니다. 시스템은 여전히 A, B, C가 모두 동일한 순서로 보였는지 확인해야 합니다. 이 시스템은 분산 프로토콜을 통해 구현되며, 우리가 A, B, C를 순차적으로 보았는지 확인합니다. 문제는 당신이 실수를 하거나, 당신의 소프트웨어가 오류를 발생시킬 경우입니다. 예를 들어, 당신의 휴대폰이 당신의 자산을 제어하고, 당신의 컴퓨터가 당신의 자산을 제어하는 경우, 당신의 휴대폰은 A가 먼저 발생했다고 표시하고, 당신의 컴퓨터는 B가 먼저 발생했다고 표시합니다. 당신은 두 가지 다른 일을 잘못 정렬했습니다. 이는 모순입니다. 이 경우 Sui는 "좋습니다, 저에게 순서를 알려줄 사람은 두 가지 모순된 정보를 주었으므로, 저는 어떻게 해야 할지 모르겠습니다. 이 문제를 해결하는 방법을 모르겠습니다."라고 말합니다. Sui는 일반적으로 이 문제를 합의 경로를 통해 해결합니다. 그러나 여기서는 당신이 빠른 경로를 사용하려고 하고 있습니다. 그래서 Sui는 손을 들어 "좋습니다, 여기서 오류가 발생했습니다."라고 말합니다.

초기 가정은 이러한 상황이 자주 발생하지 않을 것이라는 것이었지만, 사실 사람들은 서로 다른 장치를 사용하거나 동일한 객체에 대해 동시에 여러 번 거래를 시도하기 때문에 자주 발생하는 것으로 나타났습니다. 현재 이러한 객체가 잠길 때, Sui는 한 epoch가 끝날 때까지 기다려야 잠금을 해제합니다. 이는 매우 우려스러운 일입니다. 만약 당신의 자산이 하루 동안 사용할 수 없다면, 이는 실제로 심각한 문제가 될 수 있습니다.

따라서 이제 Sui는 어떤 것이 잠길 때 올바른 조치를 취할 수 있도록 발전해야 합니다. 만약 올바른 순서를 제공해야 하는 주체가 모호한 순서를 제공한다면, Sui는 전체 상황을 합의를 통해 해결할 것입니다. 이는 몇 초 내에 발생할 것이며, 한 epoch가 끝날 때 발생하는 것이 아닙니다. Q10 당신의 많은 연구는 프라이버시를 중심으로 진행되었습니다. 공공 블록체인이 투명성, 추적 가능성 및 프라이버시를 어떻게 가장 잘 균형을 맞출 수 있다고 생각하십니까?

공공 블록체인에서 투명성, 추적 가능성 및 프라이버시의 균형을 맞추는 것은 애플리케이션과 매우 관련된 문제입니다. 제가 프라이버시에 대해 가진 관점은 무엇이 프라이버시를 유지해야 하는지는 애플리케이션 자체에 크게 의존한다는 것입니다. 예를 들어, Sui에서는 애플리케이션 개발자가 사용자 프라이버시를 보호하기 위해 계약을 개발하는 것이 합리적입니다. 어떤 사람들은 단순히 게임을 개발하고 싶어하며, 프라이버시 문제에 대한 관심이 그리 크지 않을 수 있습니다. 어떤 사람들은 블록체인에서 금융 거래를 처리하고 싶어하며, 프라이버시가 더 우려될 수 있지만, 동시에 다른 종류의 규제 문제도 포함될 수 있습니다. 그래서 Sui의 태도는 "우리는 당신에게 훌륭한 플랫폼을 제공할 것이며, 당신은 이 플랫폼에서 프라이버시를 구축해야 합니다."입니다.

사람들이 프라이버시를 구축하는 데 도움을 주기 위해, Sui는 스마트 계약 설계 시 유용할 수 있는 몇 가지 암호화 원주 지원을 제공합니다. 그 중 가장 중요한 것은 Sui에서 제로 지식 증명을 검증하는 능력입니다. 가장 널리 사용되고 이해되는 방법 중 하나인 Groth16 방법을 검증하는 로컬 함수가 있습니다. 이는 실제로 앱 설계자가 특정 이벤트를 체인 외부에서 검증할 수 있도록 하며, 이러한 이벤트가 무엇인지 공개할 필요가 없음을 의미합니다. 이는 일부 상태를 체인 외부에 유지하면서, 체인에서 체인 외부에서 발생한 모든 것이 올바른지 검증할 수 있는 프라이버시 친화적인 애플리케이션을 구축하는 기본 빌딩 블록입니다.

애플리케이션 개발자는 그들의 애플리케이션이 어떤 종류의 프라이버시 보호가 필요한지를 결정하고, 이러한 원주 지원을 사용하여 체인 상, 체인 하, 체인 상 암호화 등의 전략을 조합하여 그들이 직면할 수 있는 프라이버시 문제를 해결합니다. Q11 Sui에는 더 많은 프라이버시 원주 지원이 있습니까?

커뮤니티는 개발자가 더 프라이버시 친화적인 환경에서 스마트 계약을 작성하는 데 필요한 지원을 고려하고 있으며, 제로 지식 증명이 그 중 하나입니다. 일부 사람들은 Sui가 체인 상에서 더 일반적인 수학적 또는 암호학적 함수가 필요하다고 생각할 수 있습니다. 우리는 스마트 계약 설계자가 부족한 부분에 대한 피드백을 제공하는 것을 기꺼이 보고 싶어하며, 프라이버시를 보호하기 위해 사용할 수 있는 다른 기술들, 예를 들어 다자간 계산이나 신뢰할 수 있는 하드웨어와 같은 기술이 있습니다. 서로 다른 블록체인은 이러한 방향으로 발전하고 있으며, 이는 매우 복잡한 추가 시스템을 필요로 합니다. 커뮤니티 내에서 사람들이 이러한 기술을 원한다는 충분한 증거가 필요합니다. 왜냐하면 이는 Sui 아키텍처의 일부 기본적인 변화를 나타내기 때문입니다. 그러나 커뮤니티가 이 방향으로 발전하고자 한다면, 프라이버시 보호 방법을 추가하자는 제안 프로세스가 있을 것입니다. Q12 앞으로 6개월에서 12개월 내에 Sui는 어떻게 발전할 것이라고 생각하십니까?

이는 사람들이 Sui에서 어떤 애플리케이션을 개발했는지에 따라 달라집니다. 단기적으로는 많은 개선이 사람들이 실제로 구축한 애플리케이션을 대상으로 할 것입니다. 매우 장기적인 관점에서 볼 때, 블록체인 기준으로 6개월에서 12개월은 매우 긴 시간으로 간주될 수 있으며, 우리는 Sui Lutris 프로토콜을 개선하여 더 낮은 지연 시간과 더 간단한 프로토콜을 구현하여 Sui가 더 잘 확장될 수 있도록 할 것입니다. 또한 경제를 더 효율적으로 만들어 검증 노드가 더 제한된 하드웨어에서 실행될 수 있도록 하고, 기존 하드웨어를 실제 거래 실행에 사용할 수 있도록 하여 암호학적 또는 블록체인의 다른 오버헤드를 줄일 것입니다. 이는 우리가 기대하는 내용입니다.