bonsol 소개: 솔라나 위의 ZK, 검증 가능한 컴퓨팅이 가져올 새로운 사용 사례들은?
글: Austbot
번역: TechFlow
Anagram Build는 대부분의 시간을 새로운 암호화 사용 사례 연구에 할애하며, 이러한 사례를 특정 제품에 적용합니다. 최근 저희 팀은 검증 가능 컴퓨팅(VC) 분야로 연구 범위를 확장했으며, 이를 기반으로 Bonsol이라는 새로운 오픈소스 시스템을 개발했습니다. VC 분야를 선택한 이유는 이 기술이 제공하는 실질적인 사용 사례가 많고, 다양한 L1 블록체인이 VC의 비용 효율성과 확장성을 최적화하기 위해 노력하고 있기 때문입니다.
본 글에서는 두 가지 목표를 가지고 있습니다.
-
첫째, VC라는 개념과 그것이 Solana 생태계에서 어떤 제품을 가능하게 할 수 있는지에 대해 더 나은 이해를 제공하고자 합니다.
-
둘째, 저희의 최신 작품인 Bonsol을 소개하고자 합니다.
검증 가능 컴퓨팅이란 무엇인가?
"검증 가능 컴퓨팅(Verifiable Compute)"이라는 용어는 호황기 스타트업의 투자 설명서에는 자주 등장하지 않지만, "제로 낼리지(ZK)"라는 용어는 자주 보입니다. 그렇다면 이 용어들은 정확히 무엇을 의미할까요?
검증 가능 컴퓨팅(VC)은 특정 작업 부하를 실행하면서 그 작업 과정의 증명을 생성하는 방식으로, 이 증명은 계산을 다시 수행하지 않고도 공개적으로 검증될 수 있습니다. 제로 낼리지(ZK)란 데이터나 계산에 관한 진술을 모든 입력 데이터를 공개하지 않고도 증명할 수 있는 능력을 말합니다. 현실 세계에서는 이 두 용어가 다소 혼동되며, ZK라는 명칭 자체가 약간의 오명을 가지고 있습니다. 사실상 중요한 것은 어떤 정보를 공개하여 진술을 입증할 것인지 선택하는 문제입니다. 따라서 VC가 더 정확한 용어이며, 많은 기존 분산 시스템 아키텍처의 궁극적인 목표입니다.
VC가 왜 더 나은 암호화 제품 구축에 도움이 되는가?
그렇다면 우리는 왜 Solana나 이더리움 같은 플랫폼에 VC 또는 ZK 시스템을 추가하고자 하는 것일까요? 그 답은 주로 개발자의 보안과 관련이 있습니다. 시스템 개발자는 사용자가 신뢰하는 '블랙박스'와 그 신뢰를 객관적으로 유효하게 만드는 기술 기능 사이의 중개자 역할을 합니다. ZK/VC 기술을 활용함으로써 개발자는 제품의 공격 표면을 줄일 수 있습니다. VC 시스템은 신뢰의 초점을 증명 시스템과 증명 대상이 되는 계산 작업 부하로 옮깁니다. 이는 일반적인 Web2 클라이언트/서버 방식에서 Web3 블록체인 방식으로 전환할 때 발생하는 신뢰의 역전과 유사합니다. 즉, 회사의 약속에 의존하는 신뢰에서 오픈소스 코드와 네트워크의 암호화 시스템을 신뢰하는 것으로 변화하는 것입니다. 사용자 관점에서 보면 진정한 '제로 트러스트' 시스템은 존재하지 않으며, 사용자에게 모든 것이 여전히 하나의 블랙박스처럼 보입니다.
예를 들어, ZK 기반 로그인 시스템을 사용하면 개발자가 안전한 데이터베이스와 인프라를 유지보수해야 하는 책임이 줄어듭니다. 왜냐하면 해당 시스템은 특정 암호화 속성이 충족되었는지 여부만 검증하면 되기 때문입니다. VC 기술은 합의가 필요하며 그 합의 조건이 수학적으로 유효해야 하는 곳이라면 어디든 적용되고 있습니다.
현실에서 VC 및 ZK를 성공적으로 활용한 사례가 많지만, 이들 대부분은 프로덕션 환경에서 충분히 빠르고 효율적이게 만들기 위해 암호화 소프트웨어 스택 각 단계의 개발 진척도에 의존하고 있습니다.
저희 Anagram 팀은 업무의 일환으로 수많은 암호화 창업자 및 개발자들과 대화하며 현재 암호화 소프트웨어 스택 상태가 제품 혁신에 어떤 영향을 미치는지 파악할 수 있었습니다. 과거의 대화들을 통해 흥미로운 추세 하나를 발견하게 되었습니다. 즉, 일부 프로젝트들이 체인 상의 제품 로직을 체인 외부로 이전하고 있는데, 이는 체인 상에서 너무 비싸지거나 더 복잡한 비즈니스 로직을 추가해야 하기 때문입니다. 결국 이러한 개발자들은 점점 더 강력해지는 제품의 체인 내외 부분을 균형 있게 연결할 수 있는 시스템과 도구를 찾으려 하고 있습니다. 바로 여기서 VC가 신뢰할 수 없지만 검증 가능한 방법으로 체인 내외 세계를 연결하는 데 핵심적인 역할을 하게 됩니다.
현재의 VC/ZK 시스템은 어떻게 작동하는가?
현재 VC 및 ZK 함수는 롤업, 사이드체인, 리레이어, 오라클, 코프로세서 등의 대체 컴퓨팅 계층에서 실행되며, 스마트 컨트랙트 런타임의 콜백을 통해 사용됩니다. 이러한 워크플로우를 구현하기 위해 많은 L1 체인들이 체인 상에서 너무 비쌀 수 있는 작업을 수행할 수 있도록 스마트 컨트랙트 런타임 외부의 단축 경로(예: 시스템 호출 또는 사전 컴파일) 제공을 위해 노력하고 있습니다.
현재의 VC 시스템에는 몇 가지 일반적인 패턴이 있습니다. 제가 알고 있는 네 가지 패턴을 언급하겠습니다. 마지막 경우를 제외하면, ZK 증명은 체인 외부에서 생성되지만, 언제 어디서 증명이 검증되는지가 각각의 패턴에 장점을 부여합니다.
완전한 체인 내 검증
Groth16이나 일부 Plonk 변종처럼 작은 증명을 생성할 수 있는 VC 및 ZK 증명 시스템의 경우, 증명은 체인 상으로 제출되며 이전에 배포된 코드를 사용해 체인 상에서 검증됩니다. 이러한 시스템은 이미 매우 흔하며, 이 방식을 시도하는 가장 좋은 방법은 Circom과 Solana 또는 EVM 상의 Groth16 검증기를 사용하는 것입니다. 단점은 이러한 증명 시스템이 상당히 느리다는 점입니다. 또한 새로운 언어를 배워야 하는 경우가 많습니다. 예를 들어, Circom에서 256비트 해시를 검증하려면 실제로 각 256비트를 수동으로 처리해야 합니다. 여러 라이브러리를 통해 해시 함수를 간단히 호출할 수 있지만, 내부적으로는 Circom 코드에 해당 함수를 다시 구현해야 합니다. ZK 및 VC 요소가 작고, 다른 결정적 작업을 수행하기 전에 증명이 유효함을 입증해야 할 때 이러한 시스템은 매우 유용합니다. Bonsol은 현재 이 첫 번째 범주에 속합니다.
체인 외부 검증
증명은 모든 참여자가 볼 수 있도록 체인 상에 제출되며, 이후 체인 외부에서 검증됩니다. 이 모드에서는 어떤 증명 시스템도 지원할 수 있지만, 증명이 체인 상에서 검증되지 않기 때문에 증명 제출에 따라 이루어지는 작업에 대해 동일한 확정성을 얻을 수 없습니다. 그러나 일정한 도전 기간(challenge window)이 있는 시스템에는 적합합니다. 이 경우 참여자들이 "거부권"을 행사하며 증명이 잘못되었음을 입증할 수 있습니다.
검증 네트워크
증명은 검증 네트워크에 제출되며, 이 네트워크는 스마트 컨트랙트를 호출하는 오라클 역할을 합니다. 확정성을 얻을 수 있지만, 동시에 검증 네트워크를 신뢰해야 합니다.
동기식 체인 내 검증
네 번째이자 마지막 패턴은 다소 독특합니다. 이 경우 증명과 검증이 동시에 체인 상에서 이루어집니다. 즉, L1 또는 L1 상의 스마트 컨트랙트가 사용자 입력 위에서 ZK 방식을 실행하고, 개인 데이터 상의 실행을 증명할 수 있게 됩니다. 실제 사례는 많지 않으며, 일반적으로 이 방식으로 할 수 있는 일은 더 기본적인 수학 연산에 국한됩니다.
요약
이 네 가지 패턴 모두 다양한 체인 생태계에서 실험되고 있으며, 새로운 패턴이 나타날지, 그리고 어떤 패턴이 주류가 될지 지켜볼 필요가 있습니다. 예를 들어, Solana에서는 아직 명확한 승자가 없으며, VC 및 ZK 분야는 초기 단계에 있습니다. Solana를 포함한 여러 체인에서 가장 인기 있는 접근법은 첫 번째 패턴입니다. 완전한 체인 내 검증은 금자탑(Golden Standard)이지만, 앞서 논의한 바와 같이 지연 시간과 회로 기능 제한이라는 단점도 존재합니다. Bonsol에 대해 자세히 살펴보면, 이 첫 번째 패턴을 따르지만 몇 가지 차이점이 있음을 알 수 있습니다.
Bonsol 소개
Bonsol은 Anagram이 구축하고 오픈소스로 공개한 Solana 네이티브 VC 시스템입니다. Bonsol은 개발자가 개인 데이터와 공용 데이터를 포함하는 검증 가능한 실행 파일을 만들고, 그 결과를 Solana 스마트 컨트랙트에 통합할 수 있게 해줍니다. 참고로 이 프로젝트는 인기 있는 RISC0 도구 체인에 의존합니다.
이 프로젝트의 영감은 매주 다양한 프로젝트와 교류하며 자주 받는 질문에서 비롯되었습니다. "어떻게 하면 개인 데이터를 사용해 체인 상에서 그것을 증명할 수 있을까?" 상황마다 "그것"은 다르지만, 근본적인 바람은 동일합니다. 즉, 중심화된 의존도를 줄이고 싶다는 것입니다.
시스템의 세부 사항에 깊이 들어가기 전에, 두 가지 다른 사용 사례를 통해 Bonsol의 강력함을 설명하겠습니다.
시나리오 일
Dapp이 사용자가 다양한 토큰 풀에서 복권을 구매할 수 있게 합니다. 이 풀들은 매일 글로벌 풀에서 "기울어져" 생성되며, 풀 내의 금액(각 토큰별 금액)은 숨겨져 있습니다. 사용자는 풀 내 토큰의 점점 더 구체적인 범위에 대한 접근 권한을 구입할 수 있습니다. 하지만 함정이 있습니다. 사용자가 해당 범위를 구매하면, 즉시 모든 사용자에게 공개됩니다. 그 후 사용자는 복권을 구매할지 결정해야 합니다. 구매가 가치 없다고 판단하거나, 복권을 구매해 풀 내 자신의 지분을 확보할 수도 있습니다.
풀이 생성되거나 기울어질 때, 그리고 사용자가 범위에 대한 비용을 지불할 때 Bonsol이 작동합니다. 풀 생성/기울기 시점에 ZK 프로그램은 각 토큰 수량을 개인 입력으로 받습니다. 토큰 종류는 알려진 입력이며, 풀 주소 역시 알려진 입력입니다. 증명은 글로벌 풀에서 현재 풀로 무작위 선택된 것을 입증합니다. 증명에는 잔액에 대한 커밋도 포함됩니다. 체인 상의 컨트랙트는 이 증명을 수신하여 검증하고, 풀을 닫고 글로벌 풀에서 잔액을 복권 소유자에게 전송할 때까지 이 커밋을 저장합니다. 이렇게 하면 풀 시작 후 무작위 선택 이후 토큰 수량이 변경되었는지 확인할 수 있습니다.
사용자가 숨겨진 토큰 잔액 범위를 "공개"하는 것을 구매할 때, ZK 프로그램은 실제 토큰 잔액을 개인 입력으로 받아 일련의 값을 생성하고 증명과 함께 커밋합니다. 이 ZK 프로그램의 공용 입력은 이전의 풀 생성 증명 및 그 출력입니다. 이를 통해 전체 시스템이 검증됩니다. 이전 증명은 범위 증명 내에서 검증되어야 하며, 토큰 잔액은 첫 번째 증명에서 커밋된 값과 동일한 해시값이어야 합니다. 범위 증명도 체인 상에 제출되며, 앞서 언급한 바와 같이 모든 참여자에게 범위가 공개됩니다.
이러한 복권 시스템을 구현하는 방법은 다양하지만, Bonsol의 특성 덕분에 복권 운영 조직에 대한 신뢰 요구 수준이 매우 낮아집니다. 또한 Solana와 VC 시스템 간의 상호 운용성도 부각됩니다. Solana 프로그램(스마트 컨트랙트)은 증명을 검증하고 다음 단계를 진행할 수 있도록 함으로써 신뢰 형성에 핵심적인 역할을 합니다.
시나리오 이
Bonsol은 개발자가 다른 시스템에서 사용할 수 있는 도구 세트를 만들 수 있게 합니다. Bonsol은 '배포(deployment)' 개념을 포함하며, 개발자는 ZK 프로그램을 만들어 Bonsol 운영자에게 배포할 수 있습니다. Bonsol 네트워크 운영자는 현재 ZK 프로그램 실행 요청이 경제적으로 유리한지 평가하는 기본적인 방법을 가지고 있습니다. 운영자는 ZK 프로그램이 얼마나 많은 계산을 필요로 하는지, 입력 크기는 얼마인지, 요청자가 제공한 팁은 얼마인지 등의 기본 정보를 볼 수 있습니다. 개발자는 다른 Dapp들이 유용하게 사용할 것으로 생각되는 도구 세트를 배포할 수 있습니다.
ZK 프로그램 구성 시 개발자는 필요한 입력의 순서와 유형을 지정합니다. 개발자는 일부 또는 전체 입력이 사전 구성된 InputSet을 게시할 수 있습니다. 즉, 개발자는 부분 입력을 구성함으로써 사용자가 매우 큰 데이터셋 상에서 계산을 검증하도록 도울 수 있습니다.
예를 들어, 개발자가 NFT를 기반으로 체인 상 소유권 이전에 특정 지갑 그룹이 포함되었음을 입증할 수 있는 시스템을 만든다고 가정해 보겠습니다. 개발자는 방대한 역사적 거래 정보를 포함하는 사전 구성된 입력 세트를 가질 수 있습니다. ZK 프로그램은 이 세트를 검색하여 일치하는 소유자를 찾습니다. 이는 인위적인 예시이며, 여러 방법으로 구현할 수 있습니다.
또 다른 예를 생각해 보세요. 개발자가 키 페어 또는 계층적 키 페어로부터 서명이 왔음을 입증하되, 그 인증 키 페어의 공개키는 공개하지 않는 ZK 프로그램을 작성할 수 있습니다. 이것이 많은 다른 Dapp들에게 유용하다고 가정하고, 그들이 이 ZK 프로그램을 사용한다고 해봅시다. 프로토콜은 이 ZK 프로그램의 작성자에게 소액의 사용 팁을 제공합니다. 성능이 중요하기 때문에, 운영자가 이를 실행하고자 하도록 개발자는 프로그램이 빠르게 작동하게 만들도록 유인받습니다. 다른 개발자의 작업을 훔쳐서 배포하려는 사람은 ZK 프로그램 내용을 검증하기 때문에 프로그램을 일부 변경해야 하며, ZK 프로그램에 추가된 모든 작업은 성능에 영향을 미칩니다. 이것이 절대적으로 안전하다고 볼 수는 없지만, 혁신한 개발자가 보상을 받는 데 도움이 될 수 있습니다.
Bonsol 아키텍처
이러한 사용 사례들은 Bonsol의 목적을 설명하는 데 도움이 되지만, 이제 현재 아키텍처, 인센티브 모델, 실행 흐름을 살펴보겠습니다.
위 이미지는 사용자가 특정 검증 가능 컴퓨팅을 수행해야 하는 흐름을 설명합니다. 일반적으로 사용자가 특정 작업을 수행해야 하는 dapp을 통해 이루어집니다. 이는 실행 요청 형태로 표현되며, 여기에는 실행될 ZK 프로그램, 입력 또는 입력 세트, 계산이 증명되어야 할 시간, 팁(릴레이 수수료 지불 방식)이 포함됩니다. 요청은 릴레이에 의해 수신되며, 릴레이는 이 실행에 대한 소유권을 주장하고 증명 생성을 시작할지 경쟁해야 합니다. 특정 릴레이 운영자의 역량에 따라, 팁이 충분치 않거나 ZK 프로그램 또는 입력이 너무 크다면 포기할 수 있습니다. 이 계산을 실행하기로 결정하면, 실행을 주장해야 합니다. 누군가가 최초로 주장에 성공하면, 그들의 증명은 일정 시간까지 수락됩니다. 만약 그들이 제때 증명을 생성하지 못하면, 다른 노드가 실행을 주장할 수 있습니다. 주장을 위해 릴레이는 일정한 담보금을 제공해야 하며, 현재는 팁의 1/2로 하드코딩되어 있고, 올바른 증명을 생성하지 못하면 몰수됩니다.
Bonsol의 설계는 더 많은 계산이 검증되고 체인 상에서 검증되는 레이어로 이동할 것이며, Solana가 곧 VC 및 ZK의 선호 체인이 될 것이라는 주장에 기반합니다. Solana의 빠른 거래 처리, 저렴한 계산 비용, 지속적으로 성장하는 사용자 기반은 이러한 아이디어를 실험하기에 이상적인 장소입니다.
쉽게 만들 수 있었을까? 물론 아닙니다!
물론 Bonsol을 구축하는 과정에서 도전 과제가 없었던 것은 아닙니다. Risc0 증명을 Solana로 가져와 검증하려면 그 크기를 작게 만들어야 했습니다. 하지만 증명의 보안성을 희생하지 않고 이를 단순히 작게 만들 수는 없습니다. 따라서 우리는 Risc0 Stark를 약 200KB 크기의 Circom으로 감싼 후, 항상 256바이트 크기인 Groth16 증명으로 다시 감쌌습니다. 다행히 Risc0는 이를 위한 초기 도구를 제공했지만, 시스템에 많은 오버헤드와 의존성을 추가했습니다.
Bonsol 구축을 시작하고 기존 도구를 사용해 Stark를 Snark로 감쌀 때, 우리는 의존성을 줄이고 속도를 높이는 방법을 모색했습니다. Circom은 Circom 코드를 C++ 또는 wasm으로 컴파일할 수 있게 합니다. 처음에는 Circom 회로를 LLVM이 생성한 wasmu 파일로 컴파일해보았습니다. 이는 Groth16 도구모음을 이식 가능하면서도 빠르게 유지하는 가장 빠르고 효과적인 방법이었습니다. 우리는 이식성을 위해 C++보다 wasm을 선택했는데, C++ 코드는 x86 CPU 아키텍처에 의존하기 때문에 새로운 Macbook이나 Arm 기반 서버에서는 이 코드를 사용할 수 없었기 때문입니다. 하지만 우리의 일정 상 한계로 인해 이 방법은 실패했습니다. 대부분의 제품 연구 실험은 가치 입증까지 시간 제한이 있었으며, 이 아이디어를 테스트할 개발 기간은 2~4주였습니다. llvm wasm 컴파일러는 생성된 wasm 코드를 처리할 수 없었습니다. 더 많은 작업을 통해 이 문제를 해결할 수도 있었겠지만, 최적화 플래그를 시도하거나 llvm 컴파일러를 wasmer 플러그인으로 작동시켜 코드를 llvm로 사전 컴파일하는 방법을 여러 차례 시도했음에도 성공하지 못했습니다. Circom 회로가 약 150만 줄에 달하므로, 생성되는 wasm 코드의 양도 어마어마할 수 있음을 상상할 수 있습니다. 이후 우리는 C++과 Rust 기반 릴레이 코드베이스 사이에 다리를 만드는 방법을 시도했습니다. 하지만 C++ 코드에 x86 특정 어셈블리 코드가 포함되어 있어 이것을 수정하는 것은 피하고자 했기 때문에 이 시도도 금방 좌절되었습니다. 시스템을 공개하기 위해 결국 우리는 C++ 코드를 사용하되 일부 의존성을 제거한 시스템을 간단히 시작했습니다. 앞으로는 우리가 추진 중인 또 다른 최적화 경로를 확장하고자 합니다. 즉, C++ 코드를 실제로 실행 그래프로 컴파일하는 것입니다. Circom이 컴파일한 C++ 구성 요소는 매우 큰 소수 생성기가 있는 유한 체 위의 모듈러 산술 연산이 주를 이루기 때문에, 작은 단순한 C++ 구성 요소에서는 유망한 결과를 보였지만, Risc0 시스템과 결합하려면 추가 작업이 필요합니다. 왜냐하면 생성된 C++ 코드가 약 700만 줄에 달하며, 그래프 생성기가 스택 크기 제한에 도달하고, 이를 늘리면 다른 오류가 발생해 원인을 파악할 시간이 없었기 때문입니다. 일부 방법이 기대만큼 성과를 내지 못했지만, 오픈소스 프로젝트에 기여할 수 있었으며, 언젠가 이러한 기여가 상위 버전에 반영되기를 바랍니다.
다음 단계의 도전은 더 디자인 영역에 가까웠습니다. 이 시스템의 중요한 부분 중 하나는 개인 입력을 가질 수 있는 능력입니다. 이러한 입력은 어딘가에서 와야 하며, 시간 제약으로 인해 개인 입력이 시스템 내에서 폐쇄 루프를 형성할 수 있도록 고급 MPC 암호화 시스템을 추가할 수 없었습니다. 따라서 이러한 요구를 충족시키고 개발자를 막히지 않게 하기 위해, 우리는 개인 입력 서버 개념을 추가했습니다. 이 서버는 요청자가 현재 청구자의 유효성을 페이로드 서명을 통해 검증했는지 확인하고 서비스를 제공해야 합니다. Bonsol을 확장함에 따라 우리는 MPC 임계값 복호화 시스템을 구현할 계획이며, 이를 통해 릴레이 노드가 청구자가 개인 입력을 복호화할 수 있도록 허용할 수 있습니다. 모든 개인 입력에 대한 논의는 우리가 Bonsol 저장소에서 제공할 디자인 진화로 이어집니다. 즉, Bonsolace입니다. 이것은 더 간단한 시스템으로, 개발자가 자신의 인프라 위에서 쉽게 ZK 프로그램을 증명할 수 있게 해줍니다. 직접 증명한 후 동일한 증명 네트워크 계약 상에서 검증할 수 있습니다. 이 사용 사례는 개인 데이터 접근을 최소화해야 하는 고가치 개인 데이터 사례에 적합합니다.
Bonsol에 대해 우리가 다른 곳에서 Risc0를 사용하는 방식과 다르게 한 마지막 한 가지는, 입력 데이터가 ZK 프로그램에 들어갈 때 커밋(해시)을 강제로 요구한다는 점입니다. 실제로 증명자가 커밋해야 하는 입력을 스마트 컨트랙트 상에서 확인하여, 사용자가 기대하고 시스템에 전송한 입력과 일치하는지 보장합니다. 이는 일정한 비용을 발생시키지만, 그렇지 않으면 증명자가 사용자가 지정하지 않은 입력에 대해 ZK 프로그램을 실행함으로써 사기를 칠 수 있다는 의미가 됩니다. Bonsol의 나머지 개발 작업은 일반적인 Solana 개발 범주에 속하지만, 거기에 일부 새로운 아이디어를 시도했다는 점을 언급할 가치가 있습니다. 스마트 컨트랙트에서는 flatbuffers를 유일한 직렬화 시스템으로 사용했습니다. 이는 다소 새로운 기술이며, 크로스 플랫폼 SDK 생성에 적합하기 때문에 이를 발전시켜 하나의 프레임워크로 만들고자 합니다. Bonsol에 대한 마지막 한 가지는, 현재 가장 효과적으로 작동하려면 사전 컴파일이 필요하다는 점입니다. 이 사전 컴파일 계획은 Solana 1.18에서 구현될 예정이지만, 그 전까지는 팀이 이 연구에 관심을 갖고 Bonsol을 넘어서 다른 기술도 탐색하길 바랍니다.
결론
Bonsol 외에도 Anagram Build 팀은 VC 분야의 다양한 영역을 심도 있게 연구하고 있습니다. Jolt, zkllvm, spartan 2, Binius 같은 프로젝트들은 저희가 주목하고 있는 대상이며, 전형태 암호화(FHE) 분야에서 활동하는 기업들도 마찬가지입니다.
Bonsol 소프트웨어 저장소를 확인하시고, 필요한 예제나 확장하고 싶은 방식에 대해 질문을 제기하세요. 이는 매우 초기 단계의 프로젝트이며, 여러분이 크게 기여할 기회가 있습니다.
흥미로운 VC 프로젝트를 진행 중이라면, Anagram EIR 프로그램에 신청하세요.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
@anagramxyz
