노스트르 에코 개발 현황 및 이슈

지난 주, CKB 커뮤니티의 회원인 Retric이 Nostr 바인딩 프로토콜을 발표했습니다.

Nostr 바인딩 프로토콜은 Nostr 이벤트와 CKB 셀 간의 일대일 매핑을 생성하는 데 사용됩니다. 이 프로토콜을 통해 일반 사용자는 노스트르 소셜 네트워크에서 네이티브 자산을 생성하고 배포할 수 있으며, RGB++를 통해 비트코인 주소로 제어할 수도 있습니다. 그런 다음 클라이언트 측 개발자는 그 위에 제품을 구축할 수 있으며, 오프체인 서버용과 온체인 스마트 컨트랙트용의 두 시스템으로 나뉘어져 있는 이더리움 디앱과 달리 노스트르 바인딩 프로토콜은 데이터 수준이 다른 일관된 시스템을 사용하여 디앱을 구축하는 새로운 개발 패러다임을 디앱에 가져다준다고 합니다. 노스트르 바인딩 프로토콜은 향후 CKB 라이트닝 네트워크에 완벽하게 통합되어 소셜 네트워크의 네이티브 결제 문제를 해결할 수 있다고 합니다.

Nostr은 검열에 저항하는 글로벌 소셜 네트워크를 만들고자 하는 공개-개인 키 기반의 미니멀한 메시징 프로토콜로, 릴레이를 사용하여 소셜 데이터(예: 게시물)를 저장하고 클라이언트라고 하는 소프트웨어를 실행하는 사용자에게 전송합니다.

올해 3월 9일, 네르보스 재단과 ABCDE가 공동 주최한 제1회 비트코인 싱가포르 컨퍼런스에서 레트릭은 "노스트르 생태 개발"에 대한 강연을 진행했습니다. "라는 주제로 네르보스 재단과 ABCDE가 공동 주최한 첫 번째 비트코인 싱가포르 컨퍼런스에서 강연했습니다.

다음은 레트릭이 공유한 내용을 바탕으로 노스트르 프로토콜에 대한 이해를 돕고자 합니다.

노스트르 프로토콜은 오늘 컨퍼런스에서 가장 간단한 내용입니다. 노스트르 프로토콜은 오늘 세션에서 가장 간단한 내용일 것입니다. 다른 사람들이 이야기한 다른 기술이나 프로토콜에 비해 가장 이해하기 쉬운 이유는 매우 간단하기 때문입니다. <노스트르가 처음에 하려고 했던 것은 사실 '트위터'였지만, 이것은 엘론 머스크가 통제하지 않는 훨씬 더 탈중앙화된 트위터로, 나쁜 일을 하지 않고, 사람들을 차단하지 않으며, 언론의 자유가 있는 트위터입니다. 이런 소프트웨어를 만들고 싶다는 보다 현실적인 출발점에서 이 일을 하고 싶었고, 이를 위해 노스트라는 소셜 네트워크의 탈중앙화 프로토콜을 생각해 냈습니다. 그리고 사람들이 이것들이 실제로 트윗을 만드는 것 이상으로 인터넷의 더 나은 구조에 가깝고 우리가 할 수 있는 모든 종류의 애플리케이션이 있다는 것을 깨닫기 시작하는 시점까지 발전해 나가고 있습니다.

이 프로토콜을 한 문장으로 간단히 소개하겠습니다. 개인 키로 서명된 데이터 조각이며, 여러 릴레이 또는 리피터를 통해 전파된 다음 클라이언트로 전송됩니다. 그런 다음 이 데이터는 다른 릴레이 또는 리피터를 통해 전파된 다음 클라이언트로 전송됩니다. 본질적으로 고정된 형식의 데이터에 서명하고, 서명 후 여러 릴레이로 전송한 다음 다른 사용자가 클라이언트를 통해 해당 릴레이에서 데이터를 가져와 읽을 수 있도록 합니다.

Nostr의 핵심은 다음과 같습니다. Nostr의 핵심은 제이슨 구조이며, 각 필드는 의미를 나타내는 서로 다른 필드를 갖습니다. 예를 들어 공개 키는 서명할 데이터를 보내기 위해 서명하는 공개 키로, 콘텐츠 열이 있으며, 이는 내가 이 데이터에 어떤 내용을 서명한다는 것을 나타내며, 어떤 문자열이 될 수도 있고, 내가 보내는 트윗이 될 수도 있고, 숫자나 암호화된 것이 될 수도 있으며, 프로토콜에 대한 제한이 없습니다. 또한 이쪽에는 서명이 있는데, 이는 내가 보내는 이 데이터가 실제로 내 쪽에서 온 것임을 보증한다는 의미입니다.

Nostr의 핵심은 이렇게 간단합니다. 개인 키로 내가 작성한 데이터에 로컬로 서명한다는 뜻입니다. 이 데이터가 인터넷으로 전송된 후 Nostr 네트워크 구조도 매우 단순하여 릴레이와 클라이언트라는 두 개의 구조만 있습니다.

릴레이는 서버로, 누구나 설정할 수 있는 서버입니다. 이 릴레이의 역할은 인터넷에서 사람들이 방금 말한 이 데이터를 나에게 보내는 것을 듣고, 그것을 받아 저장하고, 나에게 일정량의 데이터를 요청하는 클라이언트가 있으면 그에게 주는 것입니다.

두 번째 부분은 이 데이터를 어떻게 배포할 것인지, 즉 배포에 대한 사양인데, 여기에는 실제로 많은 세부 사항이 포함될 것입니다. 예를 들어, 이 데이터를 릴레이에 전달하면 릴레이가 서로 통신을 하나요? 아니면 이 데이터를 릴레이에 전달하면 릴레이가 이 데이터를 완전히 저장한 다음 제가 요청할 때마다 데이터를 제공하나요? 노스트르의 대답은 "상관없으니 알아서 해"라는 다소 이상한 답변이지만, 가끔은 관심하지 않는 것이 더 현명한 전략이라고 생각해요. 현실에서든 온라인에서든 너무 신경 쓰다가 오히려 상처를 주는 경우도 있는 것 같아서 신경 쓰지 않는 게 사실 굉장히 재미있는 전략이라고 생각해요.

예를 들어 간단한 예를 들자면, 기존의 중앙 집중식 소셜 네트워크를 사용할 때는 기본적으로 중앙 서버에 모든 데이터가 저장됩니다. 그리고 사용자가 데이터를 요청하면 언제든지 제공할 수 있지만, 노스트르는 신경 쓰지 않으니 여기서 무슨 일이 벌어질까요? 더 크고 강해지고 싶고 모든 메시지를 저장하고 싶어하는 릴레이 운영자가 있는데, 그게 한 가지 종류입니다. 또한 매니아로서 아주 작은 노드를 갖고 싶어하는 사람들도 있는데, 저는 제가 좋아하는 사용자들의 데이터만 받습니다. 그리고 기꺼이 데이터를 받아주지만 30분 정도 지나면 더 이상 원하지 않아서 서버의 디스크 용량이 한정되어 있고 그렇게 오래 보관하고 싶지 않아서 삭제하는 경우도 있습니다.

이러므로 실제로는 다양한 역할로 진화할 것이며, 이러한 다양한 역할에는 다양한 분업이 존재하게 될 것입니다.

일반적인 현상은 대부분의 릴레이 노드가 사용자의 메시지를 일부 수신할 의향은 있지만 오랫동안 저장할 수 있다는 보장은 없다는 것입니다. 이 구조는 실제 인간 사회의 사회적 패턴에 더 적합한 것으로 보입니다. 실제 소셜 모델에서는 제가 오늘 이 자리에서 모든 사람과 이야기를 나누고, 제가 이야기하면 여러분은 제 말을 듣고 저를 알아본 다음 회의장을 떠난다고 가정해 보겠습니다. 이틀이 지나면 어떤 사람들은 기억력이 좋지 않아 내가 무슨 말을 했는지 기억하지 못하지만 어떤 사람들은 이 자리에서 녹음기를 사서 내가 말하는 모든 단어를 적어두기 때문에 이 메시지가 여러분에게 남지 않을 것입니다.

이것은 현실에서 일어나는 일과 매우 흡사하며, 노스트랄은 릴레이가 릴레이와 통신해야 하는지, 서로 동기화해야 하는지, 서로 동기화할 필요가 있는지 등 많은 세부 사항이나 다른 많은 것들을 지정하거나 신경 쓰지 않기 때문에 현실에서 일어나고 있는 일입니다. 동기화해야 한다고 명시되어 있지는 않지만, 동기화하지 않아도 된다고 명시되어 있지도 않습니다. 따라서 클라이언트로 가장하여 다른 릴레이에 가서 데이터를 요청하고 모든 데이터를 동기화하는 릴레이가 많이 있습니다. 그러나 필수 요구 사항 인 통신을해야한다는 필수 요구 사항을 수행하지 않는 이유 중 하나는이 요구 사항을 수행하면 통신을해야하기 때문에 모든 릴레이가 각 사용자의 데이터 전체 네트워크를 저장해야하므로 릴레이의 운영은 매우 큰 테스트가 될 것입니다. 아마도 전문 서비스 제공 업체 만이 운영 할 수 있고 개인 애호가는 운영 할 수 없을 수도 있습니다. 그래서 간단한 프로토콜을 만들 때 고려해야 할 사항 중 일부입니다.

요약하자면, 노스트르 프로토콜은 매우 간단하다고 생각합니다. 또 다른 흥미로운 점은 비트코인과 블록체인이 있는 이 시점에서 우리가 합의하고 싶은 것 중 하나는 마치 우리가 모두 앉아서 소셜 네트워킹을 하거나 인터넷에서 일부 제품을 사용하기 위해 통일된 형식, 통일된 프로토콜을 사용하겠다고 말하는 것처럼 매우 흥미로운 노드에서 나온다는 점입니다. 하지만 지금은 위챗, 트위터 등이 하고 있는 일들을 하기 위해 매우 간단한 데이터 구조, 매우 간단한 교환 프로토콜을 통일하려는 시도를 하고 있는 노드라고 생각합니다. 그래서 저는 아마도 여러분이 볼 수 있는 매우 단순한 프로토콜이라고 생각하며 그다지 흥미로워 보이지 않을 것입니다. 하지만 이 프로토콜이 등장하게 된 배경을 생각해보면 그 의미가 더 흥미롭게 느껴질 것입니다.

또 다른 한 가지는 집합의 구조상 실제로 클라이언트 측에서 많은 검증이 이루어진다는 것입니다. 게시하는 데이터가 실제로 신고한 공개-개인 키 쌍에 의해 전송되는지 확인하고 해당 유효성 검사만 수행하면 됩니다. 이 유효성 검사를 하는 이유는 예를 들어 내가 해서는 안 될 말을 하는 트윗을 보내면 릴레이로 전송되고, 릴레이가 유효성 검사를 하지 않으면 릴레이는 내가 이상한 문장을 위조해서 다른 사용자에게 보냈다고 말할 수 있기 때문입니다. 내가 데이터를 보낼 때 서명이 있기 때문에 데이터를 받는 클라이언트는 자신이 서명한 서명이 자신이 말한 것과 정확히 일치하는지 확인할 수 있으므로 Relay는 다른 사람을 속일 수 없습니다.

그래서 그 검증 중 하나는 검증의 서명을하는 것이고, 검증의 서명은 실제로 과거 우리의 중앙 집중식 인터넷, 예를 들어 위챗, 서버의 위챗은 자체 제어이며 서버에 무엇이든 쓸 수 있으며 모든 데이터, 모든 권한이 서버에 있기 때문에 속이지 않았다고 판단 할 수있는 수단이 없습니다. 모든 권한은 서버에 있습니다. <하지만 가장 간단한 형태의 인증을 사용하면 실제로 서버에서 권한을 빼앗아 계정을 소유한 사용자에게 권한을 부여할 수 있습니다. 공개-개인 키만 있으면 친구에게 인증을 요청하여 다른 사람이 나를 사칭하거나 옳지 않은 말을 하는 것이 아닌지 확인할 수 있습니다.

Nostr은 어떤가요? 3월에 제가 발견한 몇 가지 데이터가 있습니다. 분산형 네트워크이기 때문에 사실 통계가 잘 안 나오는데, 제가 nostr.band 웹사이트에서 얻은 데이터인데, Nostr의 총 사용자는 아마 37만 명 정도이고, 일일 활동량은 1만 2천 명 정도일 겁니다. 총 릴레이 수, 등장한 릴레이 수, 노드를 운영한 사람 수를 합치면 아마 2천 명 이상일 겁니다. 하지만 이 중 실제로 항상 온라인 상태인 노드는 200개 미만일 것입니다. 아마도 그렇기 때문에 사용자 수는 여전히 상대적으로 적을 것입니다.

비교를 위해 작년 말 200만 유저를 달성했다고 밝힌 블루스카이와 계약서를 비교해보면, 저 데이터 오른쪽에 트위터를 떠난 유저들이 어디로 갔는지 통계가 나오는데, 마스토돈이 1위인 것을 볼 수 있습니다. 마스토돈이 첫 번째이고, 마스토돈은 오래된 프로토콜 중 하나이고, 그 다음이 ost 뉴스, 그 다음이 블루스카이, 그리고 노스트르가 다섯 번째에 해당하는 작은 부분이라는 것을 알 수 있습니다.

물론 그렇게 진행되고 있습니다. 프로토콜에 제출된 제안서, 프로토콜에 PR을 제출하는 개발자, 개발 활동이나 토론 등 이런 종류의 데이터에서 볼 수 없는 많은 것들이 노스트르 뒤에서 일어나고 있고, 아마 그걸 다 집계할 방법은 없겠지만, 링크를 클릭하면 많은 일이 일어나고 있고 프로토콜에 기여하려는 사람들이 엄청나게 많다는 것을 알 수 있을 것입니다. 제가 트윗을 하는 것뿐만 아니라 많은 음악 앱, 유튜브형 앱, 블로그 앱 등 사람들이 노스트라와 함께 하고 있는 일들이 있습니다.

요약하자면, 현재 대부분의 사용자는 여전히 개발자나 제작자라고 생각합니다. 그들은 프로토콜 자체에 관심이 있고, 프로토콜에서 무언가를 개발하고 싶거나, 내가 무언가를 하고 싶은 사람이고, 프로토콜에서 그것을 할 것입니다. 프로토콜에는 일반적인 유형의 사용자가 적을 것입니다.

왜 노스트르가 이렇게 단순하고, 비전은 좋아 보이지만 개발은 별로 만족스럽지 않은가, 저는 이 세 가지 문제가 발생했기 때문이라고 생각하는데, 실제로 이 PPT를 작성하면서 실제로 클라이언트 측, 어떤 것의 제품 경험 등 작은 문제들이 굉장히 무수히 많다는 것을 알게 됐습니다. 하지만 이런 것들은 사실 명확하게 말하기가 매우 어렵기 때문에 제가 더 중요하다고 생각하는 세 가지 포인트만 인용했습니다.

첫 번째 큰 문제는 사용자가 노스트르 네트워크에서 콘텐츠를 전송하는 위치를 어떻게 알 수 있는가 하는 것입니다. 전체 노스트르 프로토콜의 작동 방식은 내가 로컬에서 무언가에 서명한 다음 수많은 릴레이에 전송할 수 있다는 것입니다. 다른 사용자는 내가 보낸 릴레이에서 데이터를 가져와서 읽을 수 있습니다. 하지만 이 모델에는 문제가 있습니다. 즉, 내가 이 데이터를 릴레이에 보낸 후 친구가 이 메시지를 읽고 싶을 때 내가 이 메시지를 어느 릴레이에 보냈는지 어떻게 알 수 있는지, 어느 릴레이에 내 데이터가 있는지 알아야만 읽을 수 있다는 것입니다. 따라서 큰 사용자 경험 문제 중 하나는 노스트르를 사용하는 많은 사람들이 친구에게 "야, 넌 어떤 릴레이를 사용하고 있니, 나도 너와 같은 릴레이를 설정해서 이 데이터를 함께 교환할 수 있게 해줘"라고 물어본다는 것입니다. 꽤나 멍청한 방법입니다.

물론 지금쯤이면 많은 개발자들이 NIP-65 제안과 같은 세부적인 솔루션을 내놓았는데, 이는 "내가 이 정보를 어느 릴레이에 넣을 것인지, 그리고 그 릴레이에 그 정보를 넣겠다"고 말한 다음 가능한 한 많은 릴레이에 그 정보를 전파하겠다는 것과 거의 같은 말입니다. 그런 다음 가능한 한 많은 릴레이에게 이 메시지를 전파하여 친구가 먼저 릴레이에 가서 내 친구가 주로 메시지를 보내는 위치에 대해 질문하도록 합니다. 이 정보를 얻은 후 그는 내가 주로 게시하는 릴레이에 가서 이 데이터를 요청하는 것이 한 가지 방법입니다.

사용자가 나에 대한 메시지를 읽을 릴레이를 정의할 수 있는 인박스(Inbox)와 아웃박스(Outbox)라는 두 가지 세분화된 모델이 있는데, 인박스와 마찬가지로 아웃박스는 내가 어떤 릴레이로부터 메시지를 읽을지 지정할 수 있습니다. 트위터에서 @나 다른 작업을 하고 싶은 경우 해당 메시지를 받은 쪽지함 릴레이로 보낼 수 있습니다. 다른 하나는 내 메시지를 릴레이 A, B, C, D로 보내겠다는 의미의 받은 편지함 릴레이로, 이는 내가 보내는 일반 릴레이 메시지 중 일부를 먼저 릴레이로 보낸다는 뜻입니다.

그러나 여기서 발생하는 기술적 문제, 즉 이 메시지가 어디에 있는지 어떻게 알 수 있느냐는 문제가 있습니다. 그래서 몇 가지 알고리즘을 통해 웹에서 가능한 한 많은 메시지를 다운로드하려고 시도하는 것이 실제로 문제가 될 것이고, 몇 가지 해결책이 있습니다. 그런 다음 다른 사람들이 일부 릴레이 숨겨진 증거 안에 일부 정보를 보내서 그가 공개 한 데이터를 몇 명의 릴레이가 계산을 할 확률을 계산하는 것으로 나타났습니다. 이 확률 계산을 통해 가능한 한 많은 데이터를 요청할 릴레이를 찾은 다음 데이터를 읽으려는 다른 사람들의 요구를 충족시키기 위해 데이터를 찾을 수 있습니다. 또한 사용자가 자신의 릴레이를 정의하고 그룹화할 수 있을 뿐만 아니라 다른 사용자가 이러한 그룹을 통해 나를 찾을 수 있도록 하는 것도 기존의 개선 프로그램 중 일부입니다.

두 번째 문제는 콘텐츠 거버넌스라는 더 심각한 문제입니다. 콘텐츠 제품이든 소셜 네트워크에 있는 콘텐츠든 해당 소셜 네트워크에서 콘텐츠를 어떻게 유지 관리할 것인지에 많은 에너지를 투입해야 합니다. 예를 들어, 누군가의 참수 장면을 담은 동영상을 트윗할 필요는 없겠지만, 이는 매우 나쁜 경험입니다. 이러한 회사에서는 보이지 않는 곳에서 많은 작업이 이루어지고 있으며, 콘텐츠를 필터링하거나 알고리즘으로 콘텐츠를 매칭하는 데 많은 인력이 필요하기 때문에 시장에서는 이러한 부분의 격차가 존재합니다. 여기에는 몇 가지 이유가 있는데, 그 중 하나는 사람들이 이 플랫폼에서 알고리즘을 거부하기 때문입니다. 사람들은 틱톡이나 유튜브가 알고리즘에 의해 통제되는 것처럼 느끼기 때문에 이 플랫폼의 알고리즘에 매우 거부감을 가지고 있지만, 사실 알고리즘이 필요하고 알고리즘을 전환할 수만 있으면 되기 때문입니다.

유튜브나 틱톡이 제공하는 알고리즘을 받아들여야만 광고를 푸시할 수 있다고 말하고 싶지 않고, 내가 원할 때마다 알고리즘을 전환할 수 있기를 원합니다. 알고리즘이 마음에 들지 않으면 옵트아웃할 수 있는 옵션이 있으며, 이러한 관점을 서서히 받아들이고 있습니다. 다만 현재로서는 콘텐츠에 대한 매뉴얼이나 일부 작업, 알고리즘 기술에 대한 일부 작업 등 모든 부분이 아직 상대적으로 부족하다는 것입니다. 그래서 이 부분은 우리가 가지고 있는 네트워크가 모든 사람들의 공통된 구성이고, 어떤 콘텐츠가 좋은지, 어떤 콘텐츠가 좋지 않은지, 어떤 콘텐츠에 관심을 가질 것인지, 어떤 콘텐츠에 관심이 없을 수 있는지, 이것은 실제로 콘텐츠 거버넌스의 문제입니다.

여기에 제가 나열한 개선 사항 중 첫 번째 라벨링 데이터는 사용자가 어떤 유형의 데이터인지 또는 속성이 무엇인지 라벨을 지정할 수 있는 Nostr의 특수한 데이터입니다. 데이터에 라벨을 붙이는 방법이지만, 아무도 이를 원하지 않기 때문에 널리 사용되지는 않습니다. 초창기 인터넷 사회에는 이런 종류의 구축 정신이 있었기 때문에 아무도 이 힘든 작업을 도와주는 사회 구성원 역할을 하려고 하지 않았습니다. 물론 일부 서비스를 전문적으로 실행하고 일부 회사의 전체 데이터 네트워크를 수집 한 다음 필터링 또는 분류를 수행하여 사용자에게 전송되는 일부 메시지에 대해 더 좋은 가능성을 높이기 위해 일부 서비스를 실행하는 데 더 많은 사람들이 있습니다. 이는 매우 좋은 솔루션이지만, 큰 문제가 있어 다시 돌아갑니다. 노스트르에서 데이터를 찾는 것이 아니라, 특히 잘 작동하는 API를 찾고 그 API의 서버에서 데이터를 찾는 경우가 됩니다. 그러면 프로토콜은 이 API 뒤에 또 다른 트위터나 WeChat으로 바뀌게 되므로 매우 좋은 해결책이 됩니다. 문제는 사람들이 이를 좋아하지 않는다는 것이고, 그렇게 하면 모든 사람이 여러분에게 스프레이를 뿌릴 것입니다.

또한 DVM이라는 프로그램이 있는데, 노스트르 프로토콜을 통해 프로토콜에 지정된 인터페이스를 사용하여 데이터의 분류나 알고리즘을 수행하려고 합니다. 즉, 라이트닝 네트워크의 사토시를 제공하면 원하는 데이터를 반환하고 데이터 형식을 지정하는 방식인데, 여기에는 몇 가지 문제가 있습니다.

또 다른 아이디어는 노스크립트인데, 이 필터링 알고리즘이나 분류에 필요한 몇 가지 기술을 가져와서 코드를 직접 콘텐츠로서 노스트르에 직접 넣고 릴레이가 저장하게 하는 것입니다. 그런 다음 클라이언트가 이 코드를 직접 가져와 로컬에서 일부 필터링을 수행하거나 추천을 수행할 수 있습니다. 물론 지금은 아직 아이디어만 있고 일부 사람들이 논의 중이기 때문에 이것은 더 나쁠 것입니다.

세 번째 심각한 문제는 사실 스타트업의 문제인 PMF입니다. 현재 노스트르의 많은 제품이나 개발자들은 많은 경쟁에 직면해야 하기 때문에 PMF를 찾을 수 없습니다. 한편으로는 중앙화된 전통적인 제품이 있고, 다른 한편으로는 웹3 블록체인 쪽이 있을 수 있습니다. 토큰을 발행하지 않고 아무것도 하지 않기 때문에 실제로 일부 비즈니스 모델이 누락되고 있으며, 이동하는 사람이 적을수록 계속 이동할 사람이 적기 때문에 네트워크 효과 문제도 직면하고 있습니다. 따라서 PMF는 큰 문제입니다.

Nostr의 가장 큰 고객은 Damus라고 하는데, 사용해보신 적이 있는지 모르겠지만 개발자가 작년 말에 2024년이 Damus의 마지막 해가 될 수 있다는 트윗을 보냈습니다. 2024년에 성공하지 못하면 더 이상 이 일을 계속할 여력이 없고 돈도 벌지 못하기 때문입니다. 따라서 소셜 네트워크의 공공재에 대한 지속 가능한 방향을 찾는 것이 중요한 문제라고 생각합니다.

여기의 모든 문제는 기회이기도 하다고 생각합니다. 예를 들어 지난번 PMF처럼 블록체인과 결합할 수 있는 곳이 많아지고, 블록체인 펀드와 결합할 수 있는 비즈니스 모델이 많아진다면 이런 공공재의 자금 조달 문제를 해결할 수 있을 거라고 생각해요.

마지막으로, 저는 노스트랄이 대안 애플리케이션을 개발할 수 있는 새로운 방법이라고 생각합니다. 대안 상품이라고 하면 두 극단만 있는 게 아니라 한쪽 극단은 블록체인, 한쪽 극단은 트위터, 이런 것만 있는 게 아니라 블록체인을 기반으로 하지는 않지만 독점 소프트웨어도 아닌 노스트라는 중간 지점이 있을 수 있다고 생각합니다. 고마워요.