원제: 프로토콜 설계: 왜 그리고 어떻게
원작자: Eddy Lazzarin
원곡: Sissi
소개:
a16z는 심층적인 기사를 통해 업계 발전의 가이드로서 암호화폐 분야에서 중요한 위치를 확립했으며, 우리의 인식과 변화를 높이는 데 필요한 지침을 제공합니다. 최근 a16z는 토큰 이코노미 이상의 이슈에 집중하고 있습니다. 첫 번째는 "토큰 디자인"에 대한 연설이었고, 이어서 "토큰학: 토큰 경제학을 넘어서"라는 기사가 이어졌고, 이제 많은 기대를 모으는 "프로토콜 디자인" 과정이 개설되었습니다. 강좌의 강사로서 a16z crypto의 CTO인 Eddy Lazzarin은 토큰 경제를 초월하는 열쇠는 프로토콜 설계에 있으며, 토큰 설계는 보조 수단일 뿐임을 거듭 강조했습니다. 프로토콜 설계에 초점을 맞춘 이 과정에서 그는 한 시간 이상 공유하여 기업가에게 귀중한 통찰력과 계시를 제공하고 프로젝트 성공에서 프로토콜 설계의 핵심 역할을 깊이 이해하도록 도왔습니다. 이 기사는 번역의 단순화된 버전입니다. 더 흥미로운 콘텐츠를 보려면 번역된 전문 버전 링크를 참조하세요.
프로토콜 진화의 고유 법칙
인터넷 프로토콜: 상호작용의 결합
인터넷은 다양한 유형의 프로토콜을 포함하는 프로토콜 네트워크입니다 . HTTP의 상태 다이어그램처럼 일부 프로토콜은 간단하고 간단하지만, Maker 프로토콜의 상호 작용 다이어그램처럼 매우 복잡한 프로토콜도 있습니다. 아래 그림은 인터넷 프로토콜, 물리적 프로토콜, 정치적 프로토콜 등을 포함한 다양한 프로토콜을 보여줍니다. 아래 그림의 왼쪽에는 우리에게 친숙하고 흥미롭게 느껴지는 교차로의 대화형 다이어그램이 있습니다.
이러한 프로토콜의 공통점은 프로토콜의 핵심 구성 요소인 복잡한 그룹 행동을 촉진하는 공식적인 대화형 시스템이라는 것입니다. 인터넷 프로토콜의 힘은 사람 간의 상호 작용뿐만 아니라 소프트웨어와의 상호 작용도 연결하는 능력에 있습니다. 우리는 소프트웨어가 적응력이 뛰어나고 효율적이며 다양한 메커니즘을 통합할 수 있다는 것을 알고 있습니다. 따라서 인터넷 프로토콜은 가장 중요한 프로토콜 유형은 아니지만 가장 중요한 프로토콜 중 하나입니다.
프로토콜의 진화: Web1 - Web2 - Web3
아래 차트에서 가로축은 프로토콜의 탈중앙화, 중앙화 정도, 즉 프로토콜에 대한 통제 정도를 나타냅니다. 수직축에는 계약의 경제 모델, 특히 경제 모델이 명시적인지 불특정인지가 있습니다. 이러한 구별은 미묘해 보일 수 있지만 중요한 결과를 가져옵니다.
Web1: 분권화 및 명확한 경제 모델 없음
Web1 시대 프로토콜(예: NNTP, IRC, SMTP, RSS)은 명확한 경제 모델 없이 가치 흐름, 소유권, 액세스 권한 및 지불 메커니즘 측면에서 중립적이었습니다. 그 중 유즈넷(Usenet)은 게시물과 파일을 교환하기 위한 오늘날의 Reddit과 유사한 프로토콜입니다. IRC는 초기에 널리 사용된 채팅 프로토콜인 반면, SMTP와 RSS는 이메일 및 콘텐츠 구독에 사용되었습니다.
유즈넷은 사용자가 특정 카테고리의 하위 서버에 관련 콘텐츠를 게시할 수 있도록 카테고리별로 구성된 플랫폼입니다. 이는 초기 인터넷 문화의 중요한 부분이었으며 HTTP 외부에 존재했습니다. 유즈넷을 사용하려면 특정 클라이언트와 유즈넷을 지원하는 인터넷 서비스 제공업체(ISP)가 필요합니다. 유즈넷은 누구나 운영할 수 있고 게시물이 자동으로 다른 서버로 전달되어 분산형 시스템을 형성할 수 있는 끊임없이 변화하는 수많은 뉴스 서버에 분산되어 있습니다. 사용자가 유즈넷 액세스 비용을 직접 지불하는 경우는 거의 없었지만 2000년대 후반 일부 사용자는 상업용 유즈넷 서버 비용을 지불하기 시작했습니다. 전반적으로 유즈넷에는 명확한 프로토콜 경제 모델이 부족하며 사용자는 자신의 거래를 통해 이를 사용해야 합니다.
이러한 Web1 프로토콜은 구조적으로 유사하며 동일한 값에서 유래합니다. 프로토콜에 대해 많이 알지 못하더라도 프로토콜이 어떻게 작동하는지 이해할 수 있습니다. 이는 Web1 프로토콜에 대한 가독성과 명확한 템플릿의 중요성을 보여줍니다. 그러나 이러한 프로토콜은 시간이 지남에 따라 점차 실패하거나 변화해 왔습니다. 실패 원인 은 첫째, Web2 경쟁업체와 경쟁할 수 있는 구체적인 기능이 부족하다는 점, 둘째, 자금 조달의 어려움 등 두 가지 측면에서 기인합니다. 궁극적으로 프로토콜의 성공은 분산형 접근 방식을 취하고 특정 기능을 통합하기 위한 지속 가능한 경제 모델을 개발하는 능력에 따라 결정됩니다. 요약하자면 Web1 프로토콜은 분산형으로 분류될 수 있으며 명확한 경제 모델이 부족합니다.
Web2: 중앙 집중화 및 명시적 경제 모델
Web2는 흥미로운 추세를 가져왔습니다. Reddit은 Usenet과 같은 포럼을 대체했으며 WhatsApp 및 iMessage와 같은 중앙 집중식 메시징 시스템은 IRC와 같은 포럼을 대체했습니다. 이메일은 여전히 존재하지만 스팸이라는 문제에 직면해 있습니다. 또한 RSS는 Twitter와 경쟁이 잘 되지 않습니다. Web2는 Web1 프로토콜의 한계를 해결하고 특정 기능을 제공합니다. 이메일 및 기타 분산형 프로토콜은 메시지 적법성, 발신자 신원, 권한 및 재정적 관계를 확인할 수 없으므로 스팸 처리가 문제가 됩니다. 미성숙한 분산형 시스템에서는 이러한 기능이 부족하여 중앙화된 경쟁자가 고유한 기능을 제공함으로써 이전 버전을 능가할 수 있습니다.
Web2 프로토콜은 소유자에 의해 완전히 통제되며 비즈니스 정책 및 법률에 의해서만 제한됩니다. Web1 프로토콜의 개발을 촉진하려면 보다 명확한 경제 모델이 필요합니다. 그러나 분산화 합의, 검증 가능한 계산 및 암호화 도구를 활용하지 않으면 분산화를 유지하면서 명확한 경제 모델을 달성하는 것이 불가능합니다. 계약은 일반적으로 디자인 공간의 왼쪽 하단에서 오른쪽 상단으로 전환됩니다. 때때로 프로토콜은 이메일처럼 사실상 중앙 집중화됩니다. 이메일의 50% 이상이 중앙 집중식 이메일 서비스 제공업체에 의해 처리되므로 이메일이 고도로 중앙 집중화됩니다. 이메일은 스팸 문제, 경제 모델 부족, DNS 등록 비용 분담 및 높은 전환 비용에 직면해 있습니다.
실행 가능한 경제 모델이 없으면 이메일은 대기업의 부수 프로젝트로만 지속 가능합니다. 스팸을 줄이는 방법은 규모의 경제와 데이터 통합에 의존하며, 수백만 개의 이메일 계정을 호스팅하는 회사는 이상 현상을 더 쉽게 감지할 수 있습니다. 또한 전환 비용도 중요한 요소입니다. 이제 우리는 프로토콜의 다양한 구성 요소에 영향 을 미치고 프로토콜 설계 과정의 모든 단계에서 지속적으로 작용하게 될 두 가지 주요 중앙 집중화 힘 , 즉 네트워크 효과와 전환 비용을 인식해야 합니다.
네트워크 효과는 시스템의 규모가 커지고 널리 사용됨에 따라 전력이 축적되는 현상입니다. 전환 비용은 사용자가 현재 시스템을 떠나 다른 시스템으로 전환하는 데 필요한 경제적, 인지적 또는 시간 비용을 의미합니다. 이메일 예에서 전환 비용은 Gmail을 사용하는 사용자에게 매우 중요합니다. Gmail을 사용하지만 자신만의 도메인 이름이 없다면 전환 비용이 많이 듭니다. 그러나 자신의 도메인 이름을 소유하고 있는 경우 이메일 서비스 제공업체를 자유롭게 전환하고 계속해서 서비스 제공업체를 이용하여 이메일을 받을 수 있습니다. 회사는 프로토콜 설계를 통해 전환 비용을 늘릴 수 있으며, 사용자가 특정 구성 요소를 사용하도록 강요하거나 권장함으로써 사용자가 다른 공급자로 전환할 가능성을 줄일 수 있습니다.
예를 들어 중재자가 하위 포럼을 일방적으로 제어하여 분산화와 중앙화 사이의 경계를 모호하게 하는 시스템인 Reddit을 예로 들어 보겠습니다. 누구나 중재자가 될 수 있도록 허용하는 것은 분산화의 한 형태로 보일 수 있지만, 궁극적인 권한이 중재자(예: Reddit 팀)의 손에 집중되어 있다면 여전히 완전히 중앙 집중화된 시스템입니다. 고품질 사용자 경험은 중앙 집중식 권력과 관련이 없지만 고품질 사용자 경험을 제공하려면 재정적 지원이 필요한 경우가 많습니다. Web1 시대에 분산형 프로토콜은 자금 부족으로 인해 좋은 사용자 경험을 제공하지 못하는 경우가 많았습니다. 재정적 지원은 고품질의 사용자 경험을 제공하는 데 중요한 역할을 합니다.
Web3: 분산되고 명확한 경제 모델
Twitter, Facebook, Instagram 또는 TikTok과 같은 Web2 플랫폼에서는 사용자 선택이 제한되어 있으며 플랫폼의 인터페이스 결정에 따릅니다. 그러나 Web3에 의해 도입된 분산형 구성 요소는 프로토콜을 어떻게 변경합니까? 암호화폐와 블록체인 기술을 활용하면 신뢰에 대한 의존도를 줄이는 동시에 경제 원칙을 명확히 하고 분산화를 지원할 수 있습니다. Web3는 개방성, 상호 운용성 및 오픈 소스 기능, 명확한 경제 모델, 프로토콜에 자금을 통합하여 지속 가능한 개발을 달성하고 모든 가치의 독점을 방지하는 기능을 제공합니다.
개발자로서 분산화되고 명확한 경제 모델을 갖춘 시스템을 구축하는 것이 최선의 선택입니다. 이는 계약 외부에서 경제적 관계가 발전하도록 허용하지 않고도 시스템의 지속적인 존재와 시스템과 관련된 경제적 관계에 대한 이해를 보장합니다. 안정성과 가치 포착은 다른 방식으로 생각해야 합니다. 분산형 시스템을 구축하기로 선택하는 것은 잠재적인 위험을 피하고 내구성이 있고 가장 큰 시스템이 될 가능성이 있는 프로젝트를 구축하기 때문에 중요합니다.
인터넷 자체가 완전히 분산된 시스템이기 때문에 인터넷 구축은 더 이상 미친 것으로 간주되지 않습니다. 마찬가지로, 오픈 소스 프로그래밍 언어를 사용하고 웹 브라우저에 의존하는 것은 야심찬 프로젝트를 구축하기 위한 견고한 기반이 되었습니다. 중앙 집중식 시스템을 구축하면 프로젝트의 규모와 범위를 확장하는 것이 제한되거나 방해될 수 있습니다. Web3는 더 크고 야심 찬 프로젝트를 구축할 수 있는 훌륭한 개발자를 끌어들입니다. 다른 시스템이나 플랫폼이 등장하여 기존 Web2 플랫폼과 경쟁하고, 규정을 준수하고 경쟁 우위를 가지며 Web2 플랫폼과 치열하게 경쟁할 수 있습니다.
Web2 네트워크의 가장 큰 문제는 취약성과 지나치게 최적화된 비즈니스 모델입니다. 이러한 네트워크는 특정 지표의 최적화를 추구하고 목표와 관련 없는 사항을 무시하므로 혁신과 신제품 개발이 부족합니다. 강력한 네트워크 효과를 갖고 있음에도 불구하고 독점을 형성할 만큼 강력하지 않으며, 약점을 노리는 대응책에 취약합니다.
이에 비해 Web3는 분산화와 명확한 경제 모델을 통해 보다 유연하고 혁신적인 공간을 제공합니다. 풍부하고 다양한 열대 우림 생태계와 마찬가지로 Web3 시스템은 모든 종류의 흥미로운 개발에 적합한 인프라와 프로토콜을 구축하여 혁신을 위한 보다 비옥한 토양을 제공합니다. 암호화폐 및 토큰 경제 모델을 활용함으로써 참가자의 창의성과 위험 감수가 보장되어 시스템 개발이 더욱 촉진됩니다.
따라서 Web3는 경제적 자원의 축적에만 의존하는 것보다 더 나은 생태계 지속 가능성과 혁신 잠재력을 가지고 있습니다 . 명확한 경제 모델과 분산형 기능을 통해 Web3는 단일 분야에 대한 과도한 최적화와 집중 축적의 딜레마에서 벗어나 진정한 의미의 혁신과 발전을 달성할 수 있습니다. 암호화 기술과 토큰 경제 모델을 도입함으로써 Web3는 참여자에게 더 큰 창의적 공간과 보상 메커니즘을 제공하여 시스템이 더 가치 있고 지속적인 방향으로 발전하도록 추진합니다.
Web3 프로토콜 설계 사례
사례 배경 및 디자인 목표
흥미로운 예부터 시작해 보겠습니다. "Stable Horde"는 이미지와 Web2 프로토콜을 생성하는 무료 시스템입니다. 사용자가 이미지 생성을 도와줄 다른 사람을 요청할 수 있는 협업 레이어 기능을 사용합니다. 클라이언트는 작업 대기열에 작업을 제출하고 작업자는 추론 처리를 수행한 후 결과 저장소로 결과를 보냅니다. 결과 저장소에서 클라이언트는 결과를 검색하고 작업자에게 Kudos 포인트를 지불할 수 있습니다. Stable Horde에서 Kudos는 작업 우선순위를 지정하는 데 사용되는 무료 포인트 시스템입니다. 그러나 기부된 컴퓨팅 리소스의 한계로 인해 대기열이 길어질수록 이미지 생성 시간도 길어집니다.
우리는 흥미로운 질문에 직면했습니다. 중앙 집중화가 프로젝트의 원래 정신을 파괴할 위험 없이 개방성과 상호 운용성을 유지하면서 이 시스템을 더 크고 전문적으로 확장할 수 있는 방법은 무엇입니까? 한 가지 제안은 Kudos 포인트를 ERC 20 토큰으로 변환하여 블록체인에 기록하는 것입니다. 하지만 단순히 블록체인만 추가하면 허위 결과 공격 등 일련의 문제가 발생할 수 있다.
프로토콜 설계 프로세스를 다시 생각해 보겠습니다. 항상 명확한 목표로 시작한 다음 제약 조건을 고려하고 마지막으로 메커니즘을 식별해야 합니다. 시스템을 설계하려면 목표를 측정하고 효과적인 메커니즘을 식별해야 합니다. 제약 조건은 내생적 형태와 외생적 형태 모두로 나타나며 설계 공간을 제한함으로써 메커니즘을 보다 명확하게 식별할 수 있습니다. 메커니즘은 청산, 가격 책정, 스테이킹, 인센티브, 지불 및 검증 등과 같은 프로토콜의 본질입니다. 설계는 제약 조건을 준수하고 명확한 목표를 충족해야 합니다.
Web3 프로토콜 예: 불안정한 혼란
"Unstable Confusion"이라는 새로운 Web3 프로토콜로 넘어가겠습니다. 다음에서는 기존 Web2 프로토콜 "Stable Horde"를 Web3 프로토콜 "Unstable Confusion"으로 변환하는 맥락에서 제안된 몇 가지 흥미로운 방향을 간략하게 설명합니다.
앞서 언급했듯이 잘못된 결과를 보내는 문제가 있으므로 사용자가 필요한 것을 얻을 수 있도록 보장하는 메커니즘이 필요합니다. 이를 "검증 추론"이라고 합니다. 간단히 말해서, 결과가 예상대로인지 확인하기 위해 추론을 검증해야 합니다. 또 다른 문제는 "Stable Horde"의 노동자와 관련이 있습니다. 작업자는 요청 순서대로 데이터베이스에 다음 작업을 요청하고 가장 먼저 요청한 작업자에게 작업을 할당합니다. 그러나 돈이 관련된 시스템에서 근로자는 실제로 작업을 완료할 의도 없이 더 많은 보상을 받기 위해 많은 작업을 요구할 수 있습니다. 그들은 낮은 대기 시간, 작업 빼앗기 및 시스템 정체를 유발하기 위해 경쟁할 수 있습니다.
위의 문제를 해결하기 위해 몇 가지 해결책이 제안되었습니다. 첫 번째 는 작업자가 기여도에 따라 급여를 받고 네트워크에 이익이 되는 방식으로 작업을 놓고 경쟁하는 "기여당 지불"입니다. 두 번째 는 '유연한 참여'입니다. 즉, 근로자가 저렴한 비용으로 자유롭게 시스템에 가입하거나 탈퇴할 수 있어 더 많은 참가자를 유치할 수 있습니다. 마지막으로 "낮은 대기 시간"이 있습니다. 즉, 애플리케이션의 응답성과 속도가 사용자 경험에 매우 중요합니다. 분산되고 상호 운용 가능한 이미지 생성 시장을 구축하는 우리의 목표로 돌아가 보겠습니다. 여전히 몇 가지 주요 제약 사항이 있지만 나중에 세부 사항을 추가, 수정하거나 더 구체적으로 지정할 수 있습니다. 이제 우리는 다양한 메커니즘의 타당성을 평가할 수 있습니다.
잠재적 메커니즘 설계
1. 검증 메커니즘
우리는 추론의 정확성을 보장하기 위해 게임 이론 및 암호화와 같은 방법을 사용할 수 있습니다. 게임 이론 메커니즘은 사용자가 특정 역할에 의해 중재되도록 분쟁을 확대할 수 있는 분쟁 해결 시스템에 사용될 수 있습니다. 연속 또는 샘플 감사는 작업자의 작업을 검토하고, 작업이 다른 작업자에게 할당되었는지 확인하고, 감사를 통과한 작업자를 기록하는 또 다른 방법입니다. 암호화의 영지식 증명은 효율적인 증명을 생성하고 추론의 정확성을 확인할 수 있습니다. 전통적인 방법에는 신뢰할 수 있는 제3자 기관과 사용자 리뷰가 포함되지만 중앙 집중화 위험과 네트워크 효과 문제가 있습니다.
다른 가능한 검증 메커니즘에는 여러 작업자가 동일한 작업을 완료한 다음 사용자가 결과에서 선택하도록 하는 것이 포함됩니다. 비용이 더 많이 들 수 있지만 비용이 충분히 낮다면 이 접근 방식을 구현하는 것을 고려해 볼 수 있습니다.
2. 가격 전략
가격 책정 전략과 관련하여 주문서는 온체인으로 설정될 수 있습니다. 가스와 같은 컴퓨팅 리소스에 대해 온체인에서 검증된 프록시 지표를 사용하는 것도 가능합니다. 이 접근 방식은 사용자가 추론에 대해 기꺼이 지불할 금액을 게시하면 작업자가 이를 수락하거나 작업 경쟁을 위해 입찰할 수 있는 단순한 자유 시장과 다릅니다. 대신 사용자는 특정 추론에 일정량의 컴퓨팅 리소스가 필요하고 컴퓨팅 리소스의 양에 따라 가격이 직접 결정되는 가스와 같은 프록시 메트릭을 만들 수 있습니다. 이러한 방식으로 전체 메커니즘의 작동을 단순화할 수 있습니다.
대안으로, 실행 비용이 더 저렴하고 잠재적으로 매우 효율적인 오프체인 주문서를 사용할 수도 있습니다. 그러나 문제는 해당 주문서를 소유한 사람이 네트워크 효과를 자신에게 집중시킬 위험이 있다는 것입니다.
3. 저장 메커니즘
작업 결과가 사용자에게 올바르게 전달되도록 하기 위해서는 저장 메커니즘이 중요하지만, 신뢰 위험을 줄이고 작업이 올바르게 전달되었는지 입증하는 것은 어렵습니다. 사용자는 예상한 상품을 받지 못했다고 불평하는 것과 유사하게 상품이 배송되었는지 여부에 대해 질문할 수 있습니다. 감사자는 계산 프로세스를 확인하고 출력 결과의 정확성을 확인해야 할 수도 있습니다. 따라서 출력은 프로토콜에 표시되어야 하며 프로토콜에 액세스할 수 있는 곳에 저장되어야 합니다.
저장 메커니즘과 관련하여 몇 가지 옵션이 있습니다. 하나는 데이터를 체인에 저장하는 것이지만 비용이 많이 듭니다. 또 다른 옵션은 전용 스토리지 암호화 네트워크를 사용하는 것인데, 이는 더 복잡하지만 P2P 방식으로 문제를 해결하려고 시도합니다. 또는 데이터를 오프체인에 저장하는 옵션이 있지만 이는 저장 시스템을 제어하는 사람이 확인 프로세스 및 최종 지불 전송과 같은 다른 측면에 영향을 미칠 수 있으므로 다른 문제를 야기합니다.
4. 업무 할당 전략
작업을 분배하는 방법도 고려해야 하는데 이는 상대적으로 복잡한 영역입니다. 작업자가 작업을 제출한 후 직접 선택하거나 작업을 제출한 후 작업을 할당하는 프로토콜 또는 사용자 또는 최종 사용자가 특정 작업자를 선택할 수 있도록 허용하는 것을 고려하세요. 각 접근 방식에는 장단점이 있으며 어떤 작업자가 어떤 작업을 요청할 수 있는지 결정하는 프로토콜 조합을 고려하십시오.
작업 할당에는 흥미로운 세부 사항이 많이 있습니다. 예를 들어, 프로토콜 기반 시스템에서는 작업자에게 작업을 할당할지 여부를 결정하려면 작업자가 온라인 상태이고 사용 가능한지 여부를 알아야 합니다. 또한 각 작업자의 능력과 부하 프로필을 이해하는 것도 필요합니다. 따라서 프로토콜에서는 다양한 추가 요소를 고려해야 하며, 이는 원래의 단순 구현에는 포함되지 않을 수 있습니다.
탈중앙화 프로토콜 설계의 핵심 포인트
중앙화 위험을 초래할 수 있는 7가지 주요 설계 요소
여기에는 이메일, 결제 시스템, 평판은 물론 저장, 매칭, 가격 책정 시스템, 검증 시스템을 통해 도입된 네임스페이스가 포함됩니다. 이러한 요소는 네트워크 효과나 높은 전환 비용으로 인해 중앙 집중화될 수 있습니다. 네트워크 효과의 축적을 완화하고, 네트워크 효과를 프로토콜로 전달하고, 프로토콜 내에 분산형 제어 계층을 구축하여 시스템의 장기적인 상태를 보장함으로써 프로토콜을 관리합니다. 분산형 제어는 휘발성 토큰이나 평판 시스템 또는 순환 선거 메커니즘과 같은 기타 거버넌스 설계를 사용하여 달성할 수 있습니다.
전환 비용 절감 및 상호 운용성 향상
기업가가 시스템에 애플리케이션을 구축하도록 장려하려면 전환 비용을 줄이고 서로 다른 시스템 간의 상호 운용성을 촉진하는 것이 중요합니다. 높은 전환 비용을 피하고 오프체인 주문장이나 제3자 검증 시스템에 대한 과도한 의존도를 줄이세요.
Web3 기술을 사용하여 분산형 시스템 구축
Web3 도구와 원칙을 사용하여 기업가에게 더 많은 권한을 부여하고 과도한 중앙 집중화를 방지하는 시스템을 설계하십시오. Web3 원칙을 수용하는 프로토콜은 일반적으로 더 큰 규모, 더 긴 수명 및 더 활기찬 생태계를 가지므로 기존 최대 기업이 설정한 경계를 넘어 혁신적인 탐색을 위한 비옥한 영역을 제공합니다.
깊이 연구하고 최상의 솔루션을 선택하세요
프로토콜을 설계하고 전략을 결정할 때 각 측면을 자세히 조사해야 합니다. 검증을 위해서는 암호화 솔루션이 최선의 선택인 경우가 많습니다. 가격 측면에서 컴퓨팅 리소스에 대해 온체인 검증 프록시 지표를 사용하면 다양한 추론 또는 기계 학습 작업을 수용할 수 있습니다. 작업 할당 측면에서는 작업자의 능력과 상태를 실시간으로 업데이트하는 프로토콜을 채택하여 작업을 공정하게 할당하고 작업자가 작업 수락 여부를 선택할 수 있도록 합니다. 저장 문제의 경우 프로토타입 샤딩 기술과 같은 솔루션을 사용하여 짧은 시간 내에 문제를 해결하고 임시 저장 방법을 채택하는 것을 고려할 수 있습니다.
분산형 시스템을 설계할 때 이러한 주요 고려 사항은 장기적인 견고성과 분산형 기능을 갖춘 시스템을 구축하는 데 도움이 될 수 있습니다.
