# Zpoken 在 Neon EVM 上成功部署 Compound 协议

By [白开水](https://paragraph.com/@baikaishui) · 2022-10-23

---

![](https://storage.googleapis.com/papyrus_images/3ac51592533fa4f4ba4e64aec6975605bf51bc260de5e4ad2747abeee854e8d5.png)

在过去的几个月里，Neon Labs 与多家组织合作，在 Neon EVM 上测试和部署各种协议和项目。Neon Labs 最近与[Zpoken](https://zpoken.io/)的合作导致在Neon EVM 上成功部署了[Compound 协议。](https://compound.finance/)在 Neon EVM 上部署 Compound 有助于进一步测试 Neon EVM 的生产准备情况以及复杂 dApp 加入其生态系统的情况。

Compound 是一个 DeFi dApp，于 2018 年 9 月在以太坊上首次推出。该协议允许用户在没有中介的情况下借出和借入加密货币。

Zpoken是谁?
---------

Zpoken 是一家全栈 Web3 开发公司。该公司已经交付了 50 多个项目，并在 10 多个区块链网络中拥有 30 名活跃的建设者。Zpoken 的专长包括高端 web3 开发、密码学、资本市场、代币设计和流动性。

我们的目标
-----

Zpoken 练习的主要目的是在将 Compound 协议合约部署到[Neon Devnet](https://proxy.devnet.neonlabs.org/solana)期间测试 Neon EVM 的性能和功能。

成功部署后，Zpoken 对该协议进行了单元测试。目标是确保协议合约的适当性能和工作流程以及合约计算和逻辑的正确性。

测试方法
----

Zpoken 测试了以下智能合约函数来验证 Compound 在 Neon EVM 上的性能：

*   将复合合约部署到 Neon Devnet 网络；
    
*   测试cToken合约函数（constructor、mint、mintFresh、redeem、redeemFreshTokens、redeemFreshAmount、liquidateBorrow、liquidateBorrowFresh、seize、\_setComptroller、transfer、balanceOfUnderlying、borrow、borrowRatePerBlock、supplyRatePerBlock、borrowBalanceCurrent、borrowBalanceStored、exchangeRateStored、getCash、borrowFresh、repayBorrowFresh、repayBorrow、repayB , accrueInterest, \_setInterestRateModel, \_setInterestRateModelFresh, \_setReserveFactor, \_setReserveFactorFresh, \_reduceReserves, \_reduceReservesFresh, admin, pendingAdmin, \_setPendingAdmin, \_acceptAdmin);
    
*   测试CEther合约函数（getCashPrior、doTransferIn、doTransferOut、mintExplicit、mintFallback、redeemCTokens、redeemUnderlying、borrow、borrowFresh、repayBorrow、repayBorrowFresh、repayBorrowBehalf、addReserves）；
    
*   测试主计长合约函数（构造函数、\_setLiquidationIncentive、\_setPriceOracle、\_setCloseFactor、\_setCollat​​eralFactor、\_supportMarket、liquidateBorrowAllowed、redeemVerify、liquidateCalculateAmountSeize、\_setPauseGuardian、设置暂停、流动性、getAccountLiquidity、getHypotheticalAccountLiquidity、admin、pendingAdmin、\_setPendingAdmin、\_acceptAdmin）；
    
*   测试 CompoundLens 合约函数（cTokenMetadata、cTokenMetadataAll、cTokenBalances、cTokenBalancesAll、cTokenUnderlyingPrice、cTokenUnderlyingPriceAll、getAccountLimits、治理、comp）；
    
*   测试 PriceOracleProxy 合约函数（构造函数，getUnderlyingPrice）；
    
*   测试Timelock合约函数（constructor、setDelay、setPendingAdmin、acceptAdmin、queueTransaction、cancelTransaction、executeTransaction、executeTransaction、queue和cancel empty）；
    
*   测试InterestRateModel合约函数（baseP025-slopeP20，跳跃率测试，baseP05-slopeP45，isInterestRateModel，计算正确的借入值，跳跃率）；
    
*   测试 CCompLikeDelegate 合约函数（\_delegateCompLikeTo）；
    
*   测试Maximillion合约函数（constructor、repayBehalf）；
    
*   测试 DAIInterestRateModelV3 合约函数（构造函数、getBorrowRate、getSupplyRate）；
    
*   测试飞轮合约函数（\_grantComp、getCompMarkets、\_setCompSpeeds、updateCompBorrowIndex、updateCompSupplyIndex、distributeBorrowerComp、distributeSupplierComp、transferComp、claimComp、claimComp batch、harnessRefreshCompSpeeds、harnessSetCompSpeeds、harnessAddCompMarkets、updateContributorRewards、\_setContributorCompSpeed）。
    

测试范围
----

测试范围集中在以下已部署的合约：

![](https://storage.googleapis.com/papyrus_images/4cfffc2d855a2351de7cdc0c0bdc45b5df47c4d517c96df303d12810ffb5a9dc.png)

测试执行
----

在部署和测试之前，Zpoken 对 Compound 协议智能合约进行了两项主要更改：

*   第一个更改是对[Timelock.sol](https://raw.githubusercontent.com/neon-smart-contract-dev/compound-finance/neon_test/contracts/Timelock.sol)中的 GRACE\_PERIOD 和 MINIMUM\_DELAY 常量进行的。常量影响合约中函数执行的时间限制。由于 Zpoken 团队在实时 Neon 网络节点上进行了测试，并且无法操纵时间和块数，因此需要进行这些更改。
    
*   第二个更改调整了[Comptroller.sol](https://raw.githubusercontent.com/neon-smart-contract-dev/compound-finance/neon_test/contracts/Comptroller.sol)合约中外部 Comp 合约的地址（通过函数 getCompAddress()）。
    

完成合约调整后，Zpoken 团队使用**_yarn deploy -n neon_**命令从存储库[neon-smart-contract-dev/compound-finance部署到 Neon Devnet。](https://github.com/neon-smart-contract-dev/compound-finance)

部署之后，从存储库[neon-smart-contract-dev/compound-finance](https://github.com/neon-smart-contract-dev/compound-finance)运行测试。要运行测试，首先需要配置本地 Neon 环境并将私钥添加到 ~/.neon/neon。运行测试的命令是\*\*\*. 启动.sh\*\*\*

[测试还通过存储库neon-smart-contract-dev/compound-finance](https://github.com/neon-smart-contract-dev/compound-finance)中的 Docker 在本地 Neon 环境中运行。进行测试的步骤如下：

1.  [使用proxy-model.py](https://github.com/neonlabsorg/proxy-model.py)运行本地 Neon 节点
    
2.  **_使用sudo docker build -t Compound-protocol_**构建 docker 镜像
    
3.  使用**_sudo docker run -it --net=host Compound-protocol运行容器_**
    

项目可交付成果包括部署和测试脚本，以及集成和单元测试。可以通过[存储库](https://github.com/neon-smart-contract-dev/compound-finance)访问部署和测试脚本。执行的集成和单元测试在[GitHub 存储库](https://github.com/neon-smart-contract-dev/compound-finance/tree/neon_test/tests)中可用，并且可以在[Docker 容器](https://github.com/neon-smart-contract-dev/compound-finance/blob/neon_test/Dockerfile)中运行以重播测试场景。

发现
--

Zpoken 成功部署并测试了 Compound 协议基础合约以及交换池。部署和相关测试表明，Neon EVM 运行正常，并且在运行 Compound 等复杂 dApp 方面与以太坊完全兼容。所有的集成和单元测试都通过了。合约部署、逻辑、数学和功能都按照 Compound 开发团队的预期工作。由于公共 GitHub 存储库中缺少 Compound API，唯一无法测试的是 Compound Web 应用程序。

Zpoken 还发现了 Neon 平台的两个问题：

1.  部署和测试 Compound 合约需要支持 RPC eth\_accounts。该方法已实施，但 Neon Labs 目前正在解决一些错误。
    
2.  Neon 网络不支持在原始 Compound 测试中实现的测试脚本的多线程执行。这些测试是为个人以太坊区块链模拟器[Ganache](https://trufflesuite.com/ganache/)而不是实时节点创建的。尝试使用多个线程会导致“nonce too low”错误。为避免该错误，应从不同的部署者地址运行每个脚本。但是，在单个测试中使用多个线程的测试中，错误是无法避免的。测试无法在这些场景中运行并被跳过。
    

结论
--

现在是**您**将自己的智能合约部署到 Neon EVM 的时候了。确保在整个过程中与我们分享您对 Neon EVM 的反馈。如果您有任何问题或需要更多指导，请查看我们的[Neon 文档或](https://docs.neon-labs.org/)[联系 Discord](https://discord.com/invite/9jVYEDVwn8)上的团队成员。我们知道你会创造出伟大的东西！

---

*Originally published on [白开水](https://paragraph.com/@baikaishui/zpoken-neon-evm-compound)*
