작성자: Austbot
편집자: 테크 플로우 (techflowpost) TechFlow
Anagram Build는 새로운 암호화 사용 사례를 연구하고 이를 특정 제품에 구현하는 데 많은 시간을 보냅니다. 가장 최근의 연구 프로젝트 중 하나는 검증 가능한 컴퓨팅(VC) 분야입니다. 우리 팀은 이 연구를 사용하여 Bonsol이라는 새로운 오픈 소스 시스템을 만들었습니다. 우리가 이 연구 영역을 선택한 이유는 검증 가능한 컴퓨팅이 많은 유효한 사용 사례를 가져오고 다양한 L1이 검증 가능한 컴퓨팅의 비용 효율성과 확장성을 최적화하기 위해 협력하고 있기 때문입니다.
이 문서에서는 두 가지 목표를 가지고 있습니다.
먼저, 우리는 솔라나 생태계에서 VC의 개념과 이를 통해 구현될 수 있는 제품에 대해 여러분이 더 잘 이해할 수 있도록 하고자 합니다.
둘째, 최신 창작물인 Bonsol을 소개하고 싶습니다.
검증 가능한 계산이란 무엇입니까?
"검증 가능한 컴퓨팅"이라는 용어는 불장(Bull market) 업의 투자 안내서에 나타나지 않을 수 있지만 "제로 지식"이라는 용어는 나타납니다. 그렇다면 이 용어들은 무엇을 의미하는가?
VC (검증 가능한 컴퓨팅 )는 계산을 다시 실행하지 않고도 공개적으로 확인할 수 있는 작업 증명을 생성하는 방식으로 특정 작업 부하를 실행합니다 . 영지식(ZK)은 계산에 대한 모든 데이터나 입력을 공개하지 않고 데이터나 계산에 대한 설명을 증명하는 능력을 말합니다. 실제 세계에서는 이러한 용어가 다소 혼동되며 ZK는 다소 잘못된 명칭입니다. 이는 진술을 입증하기 위해 공개해야 하는 정보를 선택하는 것과 더 관련이 있습니다. VC는 보다 정확한 용어이며 기존의 많은 분산 시스템 아키텍처의 전반적인 목표입니다.
VC는 어떻게 더 나은 암호화폐 제품을 구축하는 데 도움을 줄 수 있나요?
그렇다면 솔라나나 이더 같은 플랫폼에 VC나 ZK 시스템을 추가하려는 이유는 무엇일까요? 대답은 개발자 보안과 더 관련이 있는 것 같습니다. 시스템 개발자는 블랙박스에 대한 사용자의 신뢰와 그 신뢰를 객관적이고 유효하게 만드는 기술적 역량 사이에서 중개자 역할을 합니다. ZK/VC 기술을 활용하여 개발자는 자신이 제작하는 제품의 공격 표면을 줄일 수 있습니다. VC 시스템은 신뢰의 초점을 증명 시스템과 증명되는 계산 작업 부하로 전환합니다. 이는 일반적인 web2 클라이언트/서버 접근 방식에서 web3 블록체인 접근 방식으로 이동할 때 발생하는 신뢰 반전과 유사합니다. 신뢰는 회사의 약속에 의존하는 것에서 오픈 소스 코드와 네트워크의 암호화 시스템을 신뢰하는 것으로 전환됩니다. 사용자 입장에서 보면 진정한 제로 트러스트 시스템은 없고, 사용자 입장에서는 이 모든 것이 블랙박스처럼 느껴지는 것 같아요.
예를 들어, ZK 로그인 시스템을 사용하면 시스템에서 특정 암호화 속성이 구현되었는지 확인하기만 하면 되므로 개발자는 보안 데이터베이스 및 인프라를 유지 관리할 책임이 줄어듭니다. VC 기술은 필요한 합의의 유일한 조건이 수학이 유효한지 확인하기 위해 합의가 필요한 많은 장소에 적용되고 있습니다.
실제로 VC와 ZK를 사용하는 많은 성공 사례가 있지만, 이들 중 다수는 현재 암호화 소프트웨어 스택의 모든 수준에서 개발 진행 상황에 의존하여 생산에 충분히 빠르고 효율적입니다.
Anagram에서 수행하는 작업의 일환으로 우리는 암호화폐 소프트웨어 스택의 현재 상태가 제품 혁신에 어떤 영향을 미치는지 이해하기 위해 수많은 암호화폐 창립자/개발자와 대화할 기회를 가졌습니다. 역사적으로 우리의 대화는 흥미로운 추세를 파악하는 데 도움이 되었습니다. 특히, 프로젝트 그룹은 너무 비싸거나 더 이국적인 업무 로직을 추가해야 하기 때문에 온체인 제품 로직을 오프체인으로 적극적으로 이동하고 있습니다. 따라서 궁극적으로 이러한 개발자들은 개발 중인 제품의 온체인 과 오프체인 부분의 균형을 맞추는 시스템과 도구를 찾으려고 노력하며 점점 더 강력해지고 있습니다. 이것이 바로 VC가 신뢰할 수 없고 검증 가능한 방법을 사용하여 온체인 과 오프체인 세계를 연결하는 데 중요한 역할을 하는 곳입니다.
현재 VC/ZK 시스템은 어떻게 작동하나요?
오늘날 VC 및 ZK 기능은 주로 대체 컴퓨팅 계층(예: 롤업, 사이드체인, 릴레이, 오라클 또는 보조 프로세서)에서 실행되며 스마트 계약 런타임 콜백을 통해 사용할 수 있습니다. 이 워크플로를 활성화하기 위해 많은 L1 체인은 스마트 계약 런타임 외부(예: 시스템 호출 또는 사전 컴파일)에 단축키를 제공하여 온체인 에서 비용이 너무 많이 드는 일부 작업을 수행하기 위해 노력하고 있습니다.
현재 VC 시스템에는 몇 가지 공통 모델이 있습니다. 제가 아는 처음 네 가지를 언급하겠습니다. 마지막 경우를 제외하고 ZK 증명은 오프체인에서 수행되지만 이러한 모드에 각각의 이점을 제공하는 것은 증명이 검증되는 시기와 장소입니다.
완전 검증된 온 온체인
Groth16 또는 일부 Plonk 변형과 같은 소규모 증명을 생성할 수 있는 VC 및 ZK 증명 시스템의 경우 증명은 온체인 에 제출되고 이전에 배포된 코드를 사용하여 온체인 에서 검증됩니다. 이러한 시스템은 오늘날 매우 일반적이며 이를 시도하는 가장 좋은 방법은 EVM에서 Circom 및 Solana 또는 Groth16 유효성 검사기를 사용하는 것입니다. 단점은 이러한 증명 시스템이 상당히 느리다는 것입니다. 그들은 종종 새로운 언어를 배워야 합니다. Circom에서 256비트 해시를 확인하려면 실제로 각 256비트를 수동으로 처리해야 합니다. 단순히 해시 함수를 호출할 수 있는 라이브러리가 많이 있지만, 배후에서는 Circom 코드에서 이러한 함수를 다시 구현해야 합니다. 이러한 시스템은 사용 사례의 ZK 및 VC 요소가 작을 때, 그리고 다른 결정론적 조치를 취하기 전에 무언가 작동한다는 것을 증명해야 할 때 유용합니다. Bonsol은 현재 이 첫 번째 범주에 속합니다.
오프체인 검증
증거는 모든 당사자가 이를 볼 수 있고 나중에 오프체인 계산을 사용하여 확인할 수 있도록 온체인 제출됩니다. 이 모드에서는 모든 증명 시스템을 지원할 수 있지만 증명은 온체인 에서 수행되지 않으므로 증명 제출에 의존하는 작업에 대해 동일한 최종성을 얻을 수 없습니다. 이는 당사자들이 "거부권"을 행사하고 증명이 틀렸다는 것을 증명하려고 시도할 수 있는 일종의 챌린지 창을 갖춘 시스템에 유용할 것입니다.
네트워크 확인
증명은 검증 네트워크에 제출되며, 검증 네트워크는 스마트 계약을 호출하는 오라클 역할을 합니다. 확실성을 가지지만 검증 네트워크도 신뢰해야 합니다.
동기식 온체인 검증
네 번째이자 마지막 모드는 상당히 다릅니다. 이 경우 증명과 검증이 동시에 온체인 에서 수행됩니다. 이는 L1 또는 L1의 스마트 계약이 실제로 사용자 입력에 대해 ZK 체계를 실행하고 개인 데이터에 대한 실행을 입증할 수 있는 곳입니다. 광범위한 예제는 많지 않으며 일반적으로 이 접근 방식으로 수행할 수 있는 작업은 보다 기본적인 수학 연산으로 제한됩니다.
요약하다
이 네 가지 모델은 모두 다양한 체인 생태계에서 테스트되고 있으며, 새로운 모델이 등장하는지, 어떤 모델이 지배하게 될지 지켜볼 것입니다. 예를 들어 솔라나(Solana)에는 확실한 승자가 없으며 VC와 ZK 환경은 아직 초기 단계입니다. 솔라나를 포함한 많은 체인에서 가장 인기 있는 접근 방식은 첫 번째 모드입니다. 완전한 온체인 검증이 최고의 표준이지만 논의된 바와 같이 몇 가지 단점도 있습니다. 주로 대기 시간이며 회로가 수행할 수 있는 작업을 제한합니다. Bonsol을 자세히 살펴보면 첫 번째 패턴을 따르지만 몇 가지 변형이 있음을 알 수 있습니다.
본솔을 소개합니다
Bonsol은 Anagram에서 구축하고 오픈 소스로 제공하는 새로운 Solana 네이티브 VC 시스템입니다. Bonsol을 사용하면 개발자는 개인 및 공용 데이터를 포함하는 검증 가능한 실행 파일을 생성하고 그 결과를 Solana 스마트 계약에 통합할 수 있습니다. 이 프로젝트는 널리 사용되는 RISC0 도구 체인을 사용합니다.
이 프로젝트는 우리가 매주 이야기를 나누는 많은 프로젝트에 제기된 질문인 "개인 데이터를 사용하여 이를 온체인 어떻게 증명할 수 있습니까?"라는 질문에서 영감을 얻었습니다. "사물"은 각 경우마다 다르지만, 근본적인 욕구는 동일합니다. 중앙 집중식 종속성을 줄이기 위해.
시스템의 세부 사항을 살펴보기 전에 두 가지 다른 사용 사례를 통해 Bonsol의 성능을 설명해 보겠습니다.
시나리오 1
Dapp을 사용하면 사용자는 다양한 토큰 풀에서 복권을 구매할 수 있습니다. 이러한 풀은 풀의 양(각 토큰에 대한)이 숨겨지도록 글로벌 풀에서 매일 "기울어집니다". 사용자는 점점 더 구체적인 범위의 풀에 액세스하는 토큰을 구입할 수 있습니다. 하지만 문제가 있습니다. 사용자가 제품군을 구매하면 동시에 모든 사용자가 해당 제품을 사용할 수 있게 됩니다. 그런 다음 사용자는 복권 구매 여부를 결정해야 합니다. 그들은 구매할 가치가 없다고 결정할 수도 있고, 풀에 지분이 있는지 확인하기 위해 티켓을 구매할 수도 있습니다.
풀이 생성되고 사용자가 범위 비용을 지불할 때 Bonsol이 작동합니다. 풀을 생성/틸팅할 때 ZK 프로그램은 각 토큰의 양을 개인 입력으로 받습니다. 토큰 유형은 알려진 입력이고 풀 주소는 알려진 입력입니다. 증명은 글로벌 풀에서 현재 풀로 무작위로 선택되었다는 증거입니다. 증거에는 잔액 에 대한 약속도 포함되어 있습니다. 온체인 계약은 이 증거를 수신하고 이를 검증하며 풀이 최종적으로 닫히고 잔액 글로벌 풀에서 복권 소유자에게 전송될 때 무작위 선택 이후 토큰을 확인할 수 있도록 이러한 약속을 저장합니다. 수영장 시작 수량이 변경되었나요?
사용자가 숨겨진 토큰 잔액 범위가 있는 "오픈"을 구매하면 ZK 프로그램은 실제 토큰 잔액 개인 입력으로 사용하고 증명과 함께 적용되는 일련의 숫자 값을 생성합니다. 이 ZK 프로그램에 대한 공개 입력은 이전에 커밋된 풀 생성 증명과 그 출력입니다. 이러한 방식으로 전체 시스템이 검증됩니다. 이전 증명은 범위 증명에서 검증되어야 하며 토큰 잔액 첫 번째 증명에서 약속한 것과 동일한 값으로 해시되어야 합니다. 범위 증명도 온체인 제출되며, 앞서 언급한 것처럼 모든 참가자가 범위를 볼 수 있습니다.
이러한 추첨 과 유사한 시스템을 구현하는 방법에는 여러 가지가 있지만 Bonsol의 속성으로 인해 조직이 추첨 호스팅하는 데 대한 신뢰 요구 사항이 매우 낮습니다. 또한 Solana와 VC 시스템의 상호 운용성을 강조합니다. 솔라나 프로그램(스마트 계약)은 증명을 확인한 후 프로그램이 다음 조치를 취할 수 있도록 함으로써 신뢰를 형성하는 데 중요한 역할을 합니다.
시나리오 2
Bonsol을 사용하면 개발자는 다른 시스템에서 사용할 도구 모음을 만들 수 있습니다. Bonsol에는 배포 개념이 포함되어 있으며 개발자는 일부 ZK 프로그램을 만들고 이를 Bonsol 운영자에게 배포할 수 있습니다. Bonsol 네트워크 운영자는 현재 ZK 프로그램 실행 요청이 경제적으로 유리한지 여부를 평가할 수 있는 몇 가지 기본 수단을 보유하고 있습니다. ZK 프로그램에 필요한 계산 수, 입력 크기 및 요청자가 제공한 팁에 대한 몇 가지 기본 정보를 볼 수 있습니다. 개발자는 다른 많은 Dapp이 사용하고 싶어할 것으로 생각되는 도구 모음을 배포할 수 있습니다.
ZK 프로그램 구성에서 개발자는 필요한 입력 순서와 유형을 지정합니다. 개발자는 일부 또는 모든 입력으로 사전 구성된 InputSet을 게시할 수 있습니다. 이는 사용자가 매우 큰 데이터 세트에 대한 계산을 검증하는 데 도움이 되도록 부분 입력을 구성할 수 있음을 의미합니다.
예를 들어, 개발자가 온체인 소유권 이전에 NFT 기반의 특정 지갑 세트가 관련되어 있음을 증명할 수 있는 시스템을 만든다고 가정해 보겠습니다. 개발자는 대량 과거 거래 정보가 포함된 사전 구성된 입력 세트를 가질 수 있습니다. ZK 프로그램은 컬렉션을 검색하여 일치하는 소유자를 찾습니다. 이는 다양한 방식으로 구현될 수 있는 인위적인 예입니다.
또 다른 예를 생각해 보십시오. 개발자는 인증된 키 쌍의 공개 키를 공개하지 않고 키 쌍 서명이 키 쌍 또는 계층적 키 쌍에서 나오는지 확인할 수 있는 ZK 프로그램을 작성할 수 있습니다. 이것이 다른 많은 Dapp에서도 작동하고 그들이 이 ZK 프로그램을 사용한다고 가정해 보겠습니다. 이 계약은 이 ZK 프로그램 작성자에게 소액의 사용 수수료를 제공합니다. 성능이 중요하기 때문에 개발자는 운영자가 프로그램을 실행하고 싶도록 프로그램을 빠르게 실행하도록 장려되며, 다른 개발자의 작업을 훔치려는 개발자는 배포되기 전에 어떤 방식으로든 프로그램을 변경해야 합니다. ZK의 경우 프로그램의 내용이 검증됩니다. ZK 프로그램에 추가되는 모든 것은 성능에 영향을 미치며, 이는 확실히 오류가 없는 것은 아니지만 개발자가 혁신에 대한 보상을 받는 데 도움이 될 수 있습니다.
본솔건축
이러한 사용 사례는 Bonsol의 목적을 설명하는 데 도움이 되지만 현재 아키텍처, 현재 인센티브 모델 및 실행 흐름을 살펴보겠습니다.
위 이미지는 사용자가 일종의 검증 가능한 계산을 수행해야 하는 프로세스를 보여줍니다. 이는 일반적으로 사용자가 일부 작업을 수행하도록 요구하는 Dapp을 통해 달성됩니다. 이는 실행 중인 ZK 프로그램, 입력 또는 입력 세트, 계산이 입증되어야 하는 시간 및 팁(중계 비용이 청구되는 방식)에 대한 정보가 포함된 실행 요청의 형태를 취합니다. 요청은 릴레이에 의해 선택되며 릴레이는 이 실행의 소유권을 주장하고 증명을 시작할지 여부를 결정하기 위해 경쟁해야 합니다. 특정 중계 운영자의 능력에 따라 팁이 그만한 가치가 없거나 zk 프로그램 또는 입력이 너무 커서 포기하기로 선택할 수도 있습니다. 이 계산을 수행하기로 결정한 경우 이에 대한 설명을 수행해야 합니다. 진술서를 가장 먼저 입수한 경우 일정 시간까지 증거가 인정됩니다. 제때에 증거를 생성하지 못하면 다른 노드가 실행을 선언할 수 있습니다. 청구하려면 릴레이가 현재 팁/2로 하드코드된 일부 담보를 게시해야 하며, 이는 올바른 증거를 생성하지 못할 경우 삭감됩니다.
Bonsol은 더 많은 계산이 온체인 에서 확인 및 검증되는 레이어로 이동될 것이며 Solana가 곧 VC 및 ZK 가 선택하는 체인이 될 것이라는 주제를 바탕으로 구축되었습니다 . 솔라나의 빠른 트랜잭션, 저렴한 컴퓨팅, 증가하는 사용자 기반은 이러한 아이디어를 테스트하기에 좋은 장소입니다.
이거 만들기 쉽나요? 당연히 아니지!
그렇다고 본솔을 만들 때 어려움이 없었다는 것은 아닙니다. Risco0 증명을 솔라나에 가져와서 검증하려면 더 작게 만들어야 합니다. 그러나 우리는 증명의 보안을 희생하지 않고서는 이것을 할 수 없습니다. 따라서 우리는 Circom을 사용하여 약 200kb가 될 수 있는 Risc0 Stark를 래핑한 다음 항상 크기가 256바이트인 Groth16 증명으로 래핑합니다. 다행히 Risc0은 이를 위한 몇 가지 초기 도구를 제공하지만 시스템에 많은 오버헤드와 종속성을 추가합니다.
기존 도구를 사용하여 Bonsol을 구축하고 Stark 및 Snark를 래핑하기 시작했을 때 우리는 종속성을 줄이고 속도를 높이는 방법을 찾았습니다. Circom을 사용하면 Circom 코드를 C++ 또는 wasm으로 컴파일할 수 있습니다. 먼저 Circom 회로를 LLVM에서 생성된 wasmu 파일로 컴파일하려고 했습니다. 이는 Groth16 키트를 휴대 가능하면서도 빠르게 만드는 가장 빠르고 효율적인 방법입니다. 우리는 이식성 때문에 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 저장소에서 사용할 수 있도록 계획한 디자인 발전을 가져옵니다. 이것이 바로 개발자가 자신의 인프라에서 이러한 zk 프로그램을 쉽게 증명할 수 있게 해주는 더 간단한 시스템인 Bonsolace입니다. 이를 직접 증명한 후 증명 네트워크와 동일한 계약에서 검증할 수 있습니다. 이 사용 사례는 개인 데이터에 대한 액세스를 최소화해야 하는 매우 중요한 개인 데이터 사용 사례에 적합합니다.
Risc0의 다른 곳에서는 볼 수 없었던 Bonsol에 대한 마지막 요점은 입력 데이터가 zk 프로그램에 들어갈 때 입력 데이터의 커밋(해싱)을 시행한다는 것입니다. 우리는 증명자가 커밋해야 하는 입력이 사용자가 기대하고 시스템에 보내는 입력과 일치하는지 실제로 계약상으로 확인합니다. 이로 인해 약간의 비용이 발생하지만, 그렇지 않으면 증명자가 사용자가 지정하지 않은 입력에 대해 zk 프로그램을 속이고 실행할 수 있음을 의미합니다. Bonsol 개발의 나머지 부분은 일반적인 Solana 개발에 속했지만 거기에서 우리가 의도적으로 몇 가지 새로운 아이디어를 시도했다는 점에 유의해야 합니다. 스마트 계약에서는 플랫버퍼를 유일한 직렬화 시스템으로 사용합니다. 이는 크로스 플랫폼 SDK 생성에 매우 적합하므로 개발하여 프레임 로 만들고자 하는 다소 새로운 기술입니다. Bonsol에 대한 마지막 참고 사항은 현재 가장 효율적으로 작동하려면 사전 컴파일이 필요하다는 것입니다. 이 사전 컴파일은 솔라나 1.18에서 구현될 예정이지만 그때까지 우리는 팀이 이 기술과 Bonsol 이외의 다른 기술을 연구하는 데 관심이 있는지 확인하기 위해 노력하고 있습니다.
요약하다
Bonsol 외에도 Anagram 빌드 팀은 VC 세계의 여러 부분을 조사했습니다. Jolt, zkllvm, spartan 2, Binius와 같은 프로젝트가 우리가 추적하고 있는 프로젝트일 뿐만 아니라 FHE(완전 동형 암호화) 분야에서 작업하는 회사입니다.
Bonsol 소프트웨어 저장소를 확인하고 필요한 예제나 확장하려는 방식에 대한 문제를 문의하세요. 이것은 매우 초기 프로젝트이며 귀하는 빛을 발할 기회가 있습니다.
흥미로운 VC 프로젝트를 진행 중이라면 Anagram EIR 프로그램을 신청해 보세요 .
