Hey 👋🏻 noticed that you couldn't check the validity of contract interactions from inside a contract.

P.S. Sorry for the massive diff, formatters 😄

Firstly , I have already deployed *.sol in bsc testnet ,but I redeployed a second time ，and it appeared this error:

The requested contract was not found. Make sure the source code is available for compilation. I didn't change the code in the process

Firstly , I have already deployed *.sol in bsc testnet ,but I redeployed a second time ，and it appeared this error

As, the SmartWeave.contracts.readContractState method needs to load and replay all the transactions, allowing interactRead should not affect the performance.

Currently SWC offers only one way of calling other contract - ie. reading its current state: SmartWeave.contracts.readContractState(contractId: string): Promise<any>

This is somewhat limiting, as it prevents from calling any logic from external contract.

As "interactRead" does not change state (ie. it only returns "result", not new "state"), it doesn't seem to introduce any security risks.

Having such feature would allow to split business logic between different contract (eg. vesting or staking contract and PST contract).

Current workaround forces to firstly call state update on the callee contract (and wait for a transaction to be mined) - only then the "caller" contract can read updated state from "callee" contract and perform its logic.

I'll add here that anything utilizing the foreign call protocol (which will hopefully be all SmartWeave token contracts in the future) would be at risk of this without a sandbox environment because users would be able to introduce any code into the execution path of the other contracts.

Technically users could whitelist the contracts that other contracts can read from, however, this naturally puts a large limitation on who can interact with what.

I believe this has been fixed in version 0.4.33 https://github.com/ArweaveTeam/SmartWeave/commit/c154bbeb5b31ddbbdb13c18e5142b159e9be1581 (though I still believe should be taken from current block data, and not simply as Date.now().

I've noticed that block timestamp is not properly set for "interactRead" operation - ie. SmartWeave.block.timestamp inside contract's handle function returns null for such operations (it works properly for "interactWrite" though). I'm not sure why timestamp is set to null in https://github.com/ArweaveTeam/SmartWeave/blob/788a974e66494ef2ab8f876024e72bf363d4c4a4/src/contract-interact.ts#L223

Btw. - "timestamp" property does not seem to be documented in https://github.com/ArweaveTeam/SmartWeave/blob/master/CONTRACT-GUIDE.md#smartweave-global-api

Thanks.

Hey, I think we're going to need a way to run any JavaScript safely. This is going to be needed for certain things that are coming into the ecosystem such as AMM's. If we are to run random PST contracts in the browser we need to sandbox the code so it's 100% harmless. I wanted this to be the start of the discussion on the topic. I have a few ideas so far. Sandboxing can be done in two ways:

1. WASM/WASI inherently sandboxes execution. This won't be easy to do though as V8 (NodeJS JavaScript engine) doesn't support compiling to WASM
2. Running SmartWeave contracts in its own JS interpreter which can box up the code execution. See an example here: https://github.com/jterrace/js.js

Let me know your thoughts on this.

<!-- Thank you for your interest in contributing to OpenZeppelin! -->

<!-- Consider opening an issue for discussion prior to submitting a PR. --> <!-- New features will be merged faster if they were first discussed and designed with the team. -->

Fixes #???? <!-- Fill in with issue number -->

<!-- Describe the changes introduced in this pull request. --> <!-- Include any context necessary for understanding the PR's purpose. -->

PR Checklist

<!-- Before merging the pull request all of the following must be complete. --> <!-- Feel free to submit a PR or Draft PR even if some items are pending. --> <!-- Some of the items may not apply. -->

• [x] Tests
• [x] Documentation
• [x] Changelog entry

Hello @Madeindreams. The contracts in this repository are not hand-written. They are automatically transpiled from the @openzeppelin/contracts package. This "unused variable" issue is a (small) side effect from the transpiler.

A commit that changes that, such as yours, will be automatically overwritten next time the transpilling workflow is executed. This should be solved at a higher level, directly in the transpiler ... which really is not that easy to do.

I have tested and recompiled with solidity 0.8.0 using Hardhat Compiled Without warning as expected.

<!-- Thank you for your interest in contributing to OpenZeppelin! -->

<!-- Consider opening an issue for discussion prior to submitting a PR. --> <!-- New features will be merged faster if they were first discussed and designed with the team. -->

Fixes #???? <!-- Fill in with issue number -->

<!-- Describe the changes introduced in this pull request. --> <!-- Include any context necessary for understanding the PR's purpose. -->

PR Checklist

<!-- Before merging the pull request all of the following must be complete. --> <!-- Feel free to submit a PR or Draft PR even if some items are pending. --> <!-- Some of the items may not apply. -->

• [ ] Tests
• [ ] Documentation
• [ ] Changelog entry

💻 Environment

<!-- Tell us what version of OpenZeppelin Contracts you're using, and how you're using it: Truffle, Remix, etc. -->

Now I am using 3.4.1-solc-0.7-2 with Hardhat.

📝 Details

I was trying to upgrade the library with solc 0.7 support and v3.4.0-solc-0.7 is the latest solc 0.7 version, but the npm install from npmjs.com content is wrong as it's using ERC20 instead of ERC20Upgradable and my compile failed. Then I realised there's 3.4.1-solc-0.7-2 on npmjs.com but not on GitHub release. Now I am using the 0.7-2 version and has no problem.

Therefore I suggest adding the 3.4.1-solc-0.7-2 tag on Github and ask people to use 3.4.1-solc-0.7-2 instead of 3.4.0-solc-0.7

🔢 Code to reproduce bug

npm install @openzeppelin/[email protected]

Hello @leckylao, and thank you for raising that issue.

We did encounter an issue when publishing 3.4.1-solc-0.7 on npm, which required us to have this -2 fix. We are aware that this might cause issues, like the one you have been facing, and we are sorry for that.

We will take measures shortly to improve the situation.

💻 Environment

<!-- Tell us what version of OpenZeppelin Contracts you're using, and how you're using it: Truffle, Remix, etc. -->

Now I am using 3.4.1-solc-0.7-2 with Hardhat.

📝 Details

I was trying to upgrade the library with solc 0.7 support and v3.4.0-solc-0.7 is the latest solc 0.7 version, but the npm install from npmjs.com content is wrong as it's using ERC20 instead of ERC20Upgradable and my compile failed. Then I realised there's 3.4.1-solc-0.7-2 on npmjs.com but not on GitHub release. Now I am using the 0.7-2 version and has no problem.

Therefore I suggest adding the 3.4.1-solc-0.7-2 tag on Github and ask people to use 3.4.1-solc-0.7-2 instead of 3.4.0-solc-0.7

🔢 Code to reproduce bug

npm install @openzeppelin/[email protected]