AkropolisOS 이것이 무엇입니까?

AkropolisKr
Akropolis Korea
Published in
12 min readOct 24, 2020

AkropolisOS는 복잡한 dApp 및 프로토콜 (저축, 연금, 대출, 투자)을 구축하기위한 Solidity 프레임 워크입니다.

AkropolisOS는 분산 된 디지털 금융 조직을 만들고 관리하기위한 프레임 워크입니다. 누구나 AkropolisOS를 사용하여 사용자 정의 가능한 사용자 인센티브, 결합 곡선 메커니즘에 의해 활성화 된 자동화 된 유동성 제공, 프로그래밍 방식의 유동성 및 자금 관리를 통해 분산 자본 풀을 설정하고 집합 적으로 관리 할 수 ​​있습니다. OpenZeppelin을 기반으로 업그레이드 가능한 모듈 식 프레임 워크로 설계된 AkropolisOS는 일관성과 보안의 손실없이 레고와 같은 확장 성을 제공합니다.

Sparta 는 AkropolisOS를 기반으로하는 부실화 된 신용 풀로, 회원들은 다른 회원들에게 저 담보 대출을 제공하고 다양한 유동적 DeFi 도구를 통해 자본을 모으고 투자하여 고금리를 얻을 수 있습니다.

Delphi 는 달러 비용 평균 도구를 사용하는 수확량 농업 수집기입니다. Delphi를 사용하면 사용자는 통합 된 프로토콜 / 풀에서 종합적인 저축, 농장 토큰에서 수익을 얻고 능동적 인 “올인”접근 방식 또는 수동적 인 달러 비용 평균 전략을 사용하여 휘발성 자산에 투자 할 수 있습니다.

Github 저장소에 연결합니다.

메인 넷 배포

개발자 도구

다이어그램

모듈

사용자 상호 작용

전개

필요한 데이터:

  • 유동성 토큰 주소 ( LToken.address)

배포 순서 :

  1. 프록시 및 계약 인스턴스 배포
  2. 요구 initialize()
  3. 유동성 토큰
  4. 풀에 등록 : Pool.set("ltoken", LToken.address)
  5. PToken
  6. 프록시 및 계약 인스턴스 배포
  7. 요구 initialize(Pool.address)
  8. 풀에 등록 : Pool.set("ptoken", PToken.address)
  9. CurveModule
  10. 프록시 및 계약 인스턴스 배포
  11. 요구 initialize(Pool.address)
  12. 풀에 등록 : Pool.set("curve", CurveModule.address)
  13. AccessModule
  14. 프록시 및 계약 인스턴스 배포
  15. 요구 initialize(Pool.address)
  16. 풀에 등록 : Pool.set("access", CurveModule.address)
  17. 유동성 모듈
  18. 프록시 및 계약 인스턴스 배포
  19. 요구 initialize(Pool.address)
  20. 풀에 등록 : Pool.set("liquidity", LiquidityModule.address)
  21. LoanModule, LoanLimitsModule, LoanProposalsModule
  22. LoanLimitsModule의 프록시 및 계약 인스턴스 배포
  23. 요구 LoanLimitsModule.initialize(Pool.address)
  24. 풀에 등록 : Pool.set("loan_limits", LoanLimitsModule.address)
  25. LoanProposalsModule의 프록시 및 계약 인스턴스 배포
  26. 요구 LoanProposalsModule.initialize(Pool.address)
  27. 풀에 등록 : Pool.set("loan_proposals", LoanProposalsModule.address)
  28. LoanModule의 프록시 및 계약 인스턴스 배포
  29. 요구 LoanModule.initialize(Pool.address)
  30. 풀에 등록 : Pool.set("loan", LoanModule.address)
  31. FundsModule
  32. 프록시 및 계약 인스턴스 배포
  33. 요구 initialize(Pool.address)
  34. 풀에 등록 : Pool.set("funds", FundsModule.address)
  35. FundsOperator로 LiquidityModule 추가 : FundsModule.addFundsOperator(LiquidityModule.address)
  36. FundsOperator로 LoanModule 추가 : FundsModule.addFundsOperator(LoanModule.address)
  37. FundsModule을 PToken에 대한 Minter로 추가 : PToken.addMinter(FundsModule.address)

유동성

예금

필요한 데이터:

  • lAmount: 입금액, DAI

필수 조건 :

  • 모든 계약이 배포됩니다.

워크 플로우 :

  1. FundsModule.calculatePoolEnter(lAmount)예상 PTK 금액을 확인하려면 전화 ( pAmount)
  2. pAmountMin <= pAmount사용자 lAmount가 DAI를 입금 할 때받을 것으로 예상하는 최소 허용 PTK 금액을 결정 합니다. 0 값이 허용됩니다.
  3. LToken.approve(FundsModule.address, lAmount)교환을 허용하는 전화
  4. LiquidityModule.deposit(lAmount, pAmountMin)교환 실행 호출

빼다

필요한 데이터:

  • pAmount: 출금 금액, PTK

필수 조건 :

  • 사용 가능한 유동성 LToken.balanceOf(FundsModule.address)이 예상되는 DAI 금액보다 큽니다.
  • 사용자에게 충분한 PTK가 있습니다. PToken.balanceOf(userAddress) >= pAmount

워크 플로우 :

  1. FundsModule.calculatePoolExitInverse(pAmount)DAI ( lAmount) 의 예상 금액을 확인하려면 호출하십시오 . 응답에는 3 개의 값이 있으며 두 번째 값을 사용하십시오.
  2. lAmountMin <= lAmount사용자 pAmount가 PTK 입금시받을 것으로 예상하는 DAI의 최소 허용 금액 을 결정 합니다. 0 값이 허용됩니다.
  3. PToken.approve(FundsModule.address, pAmount)교환을 허용하는 전화
  4. LiquidityModule.withdraw(pAmount, lAmountMin)교환 실행 호출

크레딧

대출 요청 생성

필요한 데이터:

  • debtLAmount: 대출 금액, DAI
  • interest: 이자율, 퍼센트
  • pAmountMax: 차용자 자신의 서약으로 사용할 수있는 최대 PTK 금액
  • descriptionHash: Swarm에 저장된 대출 설명 해시

필수 조건 :

  • 사용자에게 충분한 PTK가 있습니다. PToken.balanceOf(userAddress) >= pAmount

워크 플로우 :

  1. FundsModule.calculatePoolExitInverse(pAmount)DAI ( lAmount) 에서 예상되는 약속을 결정하기 위해 호출 응답에는 3 개의 값이 있습니다. 첫 번째 값을 사용하십시오.
  2. lAmountMin <= lAmount사용자가 서약으로 잠그고 pAmountPTK를 보낼 것으로 예상하는 DAI의 최소 허용량 을 결정 합니다. 0 값이 허용됩니다.
  3. PToken.approve(FundsModule.address, pAmount)작업을 허용하려면 호출하십시오 .
  4. LoanModule.createDebtProposal(debtLAmount, interest, pAmountMax, descriptionHash)대출 제안서를 작성하려면 전화하십시오 .

향후 통화에 필요한 데이터 :

  • 제안 색인 : proposalIndex이벤트에서 DebtProposalCreated.

서약 추가

필요한 데이터:

  • 대출 제안 식별자 :
  • borrower 차용인 주소
  • proposal 제안 색인
  • pAmount 약속 금액, PTK

필수 조건 :

  • 대출 제안이 생성되었습니다.
  • 대출 제안이 아직 실행되지 않았습니다.
  • 대출 제안이 아직 완전히 채워지지 않았습니다. LoanModule.getRequiredPledge(borrower, proposal) > 0
  • 사용자에게 충분한 PTK가 있습니다. PToken.balanceOf(userAddress) >= pAmount

워크 플로우 :

  1. FundsModule.calculatePoolExitInverse(pAmount)DAI ( lAmount) 에서 예상되는 약속을 결정하기 위해 호출 응답에는 3 개의 값이 있습니다. 첫 번째 값을 사용하십시오.
  2. lAmountMin <= lAmount사용자가 서약으로 잠그고 pAmountPTK를 보낼 것으로 예상하는 DAI의 최소 허용량 을 결정 합니다. 0 값이 허용됩니다.
  3. PToken.approve(FundsModule.address, pAmount)작업을 허용하려면 호출하십시오 .
  4. LoanModule.addPledge(borrower, proposal, pAmount, lAmountMin)작업을 실행하기 위해 호출 합니다.

서약 철회

필요한 데이터:

  • 대출 제안 식별자 :
  • borrower 차용인 주소
  • proposal 제안 색인
  • pAmount 인출 할 금액, PTK

필수 조건 :

  • 대출 제안이 생성되었습니다.
  • 대출 제안이 아직 실행되지 않았습니다.
  • 사용자 서약 금액> = pAmount

워크 플로우 :

  1. LoanModule.withdrawPledge(borrower, proposal, pAmount)작업을 실행하기 위해 호출 합니다.

대출 발행

필요한 데이터:

proposal 제안 색인

필수 조건 :

  • 대출 제안이 생성되고 사용자 (거래 발신자)가 borrower
  • 대출 제안이 아직 실행되지 않았습니다.
  • 대출 제안은 전액 지원됩니다. LoanModule.getRequiredPledge(borrower, proposal) == 0
  • 풀에는 충분한 유동성이 있습니다.

워크 플로우 :

  1. LoanModule.executeDebtProposal(proposal)작업을 실행하기 위해 호출 합니다.

향후 통화에 필요한 데이터 :

  • 대출 지수 : debtIdx이벤트에서 DebtProposalExecuted.

대출 상환 (부분 또는 전액)

필요한 데이터:

  • debt 대출 지수
  • lAmount 상환 금액, DAI

필수 조건 :

  • 사용자 (거래 발신자)는 차용자입니다.
  • 대출이 아직 완전히 상환되지 않았습니다.

워크 플로우 :

  1. LToken.approve(FundsModule.address, lAmount)작업을 허용하려면 호출하십시오 .
  2. LoanModule.repay(debt, lAmount)작업을 실행하기 위해 호출 합니다.

분포

차용인이 대출의 일부를 상환 할 때, 그는 일부 PTK를 사용합니다 (잔고에서 또는 DAI를 풀로 보낼 때 발행 됨). 이 PTK는 지원자에게 제공되는 대출 부분에 비례하여 배포됩니다. 차용인 자신도 대출금의 절반을 충당했으며 그의 일부는 전체 풀에 분배됩니다. 풀의 모든 사용자는 잔액에 보유한 PTK 금액에 비례하여이 분배의 일부를 받게되며 대출 제안에서 대출 담보로 잠긴 PTK는 계산되지 않습니다.

유통 역학

모든 토큰 보유자에게 일정량의 토큰을 분배해야 할 때 첫 번째 간단한 아이디어는 모든 토큰 보유자를 반복하고 잔액을 확인하고 분배의 일부로 늘리는 것입니다. 불행히도이 접근 방식은 이더 리움 블록 체인에서 거의 사용할 수 없습니다. EVM의 모든 작업에는 약간의 가스 비용이 듭니다. 토큰 보유자가 많으면 모든 반복에 대한 가스 비용이 트랜잭션 가스 한도보다 높을 수 있습니다 (현재 블록의 가스 한도와 동일 함). 대신 배포하는 동안 배포 할 PTK의 양과 배포 할 수있는 모든 PTK의 현재 양을 저장합니다. 그리고 사용자 잔액은 별도의 요청 또는 전송, 민트 또는 소각으로 변경 될 때만 업데이트됩니다. 이 “게으른”동안 업데이트 이전 업데이트와 현재 업데이트 사이에 발생한 모든 배포를 살펴 봅니다. 이제이 업데이트와 모든 항목을 반복하기위한 가스 사용량 사이에 풀에서 너무 많은 분포가 발생하면 어떻게 될까요? 명백한 해결책은 이러한 트랜잭션을 여러 개의 작은 트랜잭션으로 분할 할 수 있도록하는 것이며 우리는이 접근 방식을 구현했습니다. 그러나 우리는 또한 하루 동안 모든 분포를 집계하기로 결정했습니다. 이런 식으로 우리는 누군가가 많은 소액 분배를 유발하는 소액 상환을 많이 할 때 먼지 공격으로부터 자신을 보호 할 수 있습니다. PToken이 배포 요청을 받으면 실제로 새 배포를 생성 할 때인 지 확인합니다. 그렇지 않은 경우 누적기에 분배 량을 추가합니다. 때가되면 (이 상태는 이적, 박하 및 화상으로도 확인됩니다)

--

--