Skip to content

스마트 계약 계층 ​

CloudBank의 온체인 레이어는 Solidity ^0.8.19 및 Foundry 툴체인(포지, 캐스트, 모루)으로 구축되었습니다. 아키텍처는 공장 복제 패턴을 사용하여 배포 비용을 최소화하는 동시에 미래 시장 유형의 전체 업그레이드 가능성을 유지합니다.

계약 계층 ​

배포 계층 구조는 레지스트리-공장-복제 구조를 따릅니다.

  • FactoryRegistry — 승인된 모든 공장 ​​계약과 배포 시장을 추적하는 중앙 등록부입니다. 시장 발견을 위한 단일 진입점 역할을 합니다.
  • DCPPFactory — EIP-1167 최소 프록시 패턴을 사용하여 이진 예측 시장을 배포합니다. DCPPFactory에 대한 각 호출은 OptimisticController 구현을 복제하고 이를 BinaryCPMM 유동성 풀과 쌍으로 만듭니다.
  • OptimisticController — 거래부터 결제까지 수명주기를 관리하는 시장별 컨트롤러입니다. 배포당 가스 비용을 ~45,000가스로 줄이기 위해 최소 프록시(클론)로 배포됩니다.
  • BinaryCPMM — YES/NO 결과 토큰 거래를 위한 지속적인 제품 자동화 시장 조성자입니다.
  • MultiOutcomeMarketFactory — 조건부 결과 슬롯 세트를 배포하여 시스템을 N-옵션 시장(예: 여러 후보가 있는 "누가 선거에서 이길까요?")으로 확장합니다.

EIP-1167 최소 프록시 패턴 ​

모든 시장에 대해 전체 계약 바이트 코드를 배포하는 대신 DCPPFactory은 OpenZeppelin의 DCPPFactory 라이브러리를 사용하여 모든 호출을 단일 구현 계약에 위임하는 경량 프록시를 배포합니다. 이를 통해 시장당 배포 비용을 약 90% 절감할 수 있습니다.

조건부 토큰 프레임워크 ​

모든 결과 위치는 Gnosis 조건부 토큰 프레임워크(CTF)를 통해 ERC-1155 토큰으로 표시됩니다. 이는 다음을 제공합니다:

  • 단일 계약 하에서 대체 가능한 결과 공유(YES 및 NO 토큰)
  • 담보를 포지션 세트로 원자적으로 분할하고 병합
  • 시장 정리 후 표준화된 상환
  • ERC-1155를 지원하는 다른 DeFi 프로토콜과의 결합성

오라클 통합 ​

  • SoraOracle — 지정된 공급자가 바이너리 질문에 답변하는 최소 yes/no 오라클 계약입니다. 분쟁 처리를 위한 7일 환불 기간이 포함됩니다.
  • SoraYesNoOracleAdapter — SoraOracle 응답을 CTF의 SoraYesNoOracleAdapter 인터페이스에 연결하여 부울 응답을 프레임워크가 기대하는 지불금 벡터 형식으로 변환합니다.

가스 후원 ​

CloudBankVerifyingPaymaster는 ERC-4337 paymaster 로직을 구현하여 플랫폼이 사용자에게 가스 요금을 후원할 수 있도록 합니다. 페이마스터는 UserOperation당 후원을 승인하기 위해 오프체인 ECDSA 서명을 검증합니다.

시장 상태 머신 ​

모든 시장은 OptimisticController에 의해 온체인으로 시행되는 결정론적 상태 시스템을 따릅니다.

  • TRADING — 시장이 활성화되었습니다. 사용자는 결과 토큰을 사고 팔 수 있습니다.
  • PROPOSED — 시장 ​​생성자가 결과를 제안했습니다. 누구나 이의를 제기할 수 있는 활성 기간이 시작됩니다.
  • DISPUTED — 분쟁이 제기되었습니다. 해결 방법은 SoraOracle로 에스컬레이션됩니다.
  • RESOLVED — 최종 결과가 설정되었습니다. 포지션 보유자는 우승 토큰을 상환할 수 있습니다.
  • CANCELLED — 시장이 무효화되었습니다. 모든 포지션은 원래 담보 가치로 상환될 수 있습니다.

시장 창출 흐름 ​

공장에서는 컨트롤러 클론을 원자적으로 배포하고, AMM 풀을 초기화하고, CTF 조건을 준비하고, 단일 트랜잭션으로 시장을 등록합니다. 제작자가 제공하는 초기 유동성은 YES 및 NO 토큰으로 분할되어 BinaryCPMM 풀에 입금됩니다.

보안 고려 사항 ​

  • 모든 계약은 상태 수정 기능에 OpenZeppelin의 OpenZeppelin을 사용합니다.
  • 액세스 제어는 명시적인 역할 분리를 통해 owner/admin 패턴을 따릅니다.
  • 시장 매개변수(활성 기간, 최소 지분)는 생성 시 검증됩니다.
  • 공장 패턴은 승인된 공장만 FactoryRegistry에 시장을 등록할 수 있도록 보장합니다.