For smart contract development, what is the difference between Openzeppelin SDK and Truffle? When should I use one or another, or both together?
OpenZeppelin Contracts: library of SmartContracts, that can be inherited and used to develop upon;
OpenZeppelin SDK: is former ZeppelinOS, it is SDK to help development process;
Truffle SDK: is well-known SDK to help development process as well. Besides SDK Truffle has other great projects as Ganache.
Spend some time to read documentation - it is very clear documented.
PS: ZeppelinOS was first SDK, that allowed to develop Upgradable Smart Contracts - really cool (https://medium.com/coinmonks/how-to-create-an-upgradeable-smart-contract-using-openzeppelin-sdk-example-of-fixing-smart-260dfbfd5bae)
Keeping things simple:
Truffle is a setup tool you can use to develop smart contracts, but doesn't touch Solidity code at all. It is like Cargo to Rust or npm/yarn to NodeJS.
OpenZeppelin is a well-tested set of libraries written in Solidity that you can import to your smart contracts while code is potentially being generated, maintained and deployed by truffle.
OpenZepplin SDK and Truffle
OpenZepplin
is a library which consist of well documented smart contracts which you can use in your projects. You can import Openzepplin library in your solidity project in order to use it.
The most obvious use of this library is for the ERC720 and ERC721 implementation.Their upgradeability concept is also one of the best.
Truffle:
is a development framework which you can use for your solidity
project. It can help you to test your developed solidity contracts by
compiling and migrating it on local test network. You can interact
with the deployed contracts thereafter either manually by using
truffle console or by running unit test which are written in
Javascript with Mocha and chai.
While building any solidity project where you are required to develop smart contracts which can use ERC token implementation or any other implementation than Openzepplin is one of the selected choice.
After your development in order to check the functionality and working of the smart contracts you developed Truffle is used.
Related
Advice for verifying contracts that were deployed through Remix using Chainlink Imports? Currently BSCScan (and I believe Etherscan) have the following limitation:
Contracts that use "imports" will need to have the code concatenated
into one file as we do not support "imports" in separate files.
The issue is that VRFConsumerBase.sol has additional imports in it as well. Making the concatenation process a bit burdensome. I've done this following #Patrick Collins's video with Hardhat pretty easily but the project I'm working with is developed in Remix.
This looks like it's working as designed unfortunately. Unless etherscan/bsscan etc changes their processes, you either have to do alot of manual appending of code.
As an alternative, you can take all the code from remix and throw into a new Hardhat project, and then use the hardhat-etherscan plugin to easily verify the contracts
When uploading solidity code to the EVM through Truffle (or anything), does it also upload supporting openzepplin contracts? If so, why does it upload "Library" type files? I thought "Library" files only needed to be uploaded once and everyone can use them?
Thanks!
I'm assuming that by "uploading" you mean deploying the compiled bytecode of your contracts on the blockchain.
When you compile your contracts you get a set of files containing bytecode, one per contract/library. If you're using contracts from OpenZeppelin by inheriting from them, their bytecode does not have to get deployed separately because it's compiled into your own contract. OZ contracts are mostly abstract, which makes the compiler not produce separate bytecode files for them anyway.
When using libraries, you only have to deploy them if you call their public or external functions. Internal functions get compiled into your own contract just as internal calls to inherited contracts. If Truffle is deploying your libraries, you probably do perform some external library calls.
I want to develop basic DAPP for banking which has functionality as withdraw, deposit, getBalance using ganache ethereum with simple UI.
If you want to learn how to develop a dapp, here is a good quickstart: Truffle-Pet shop.
It includes every essential part in developing a dapp, like truffle, ganache, smart contract, and frontend.
I hope it helps.
here is what you are looking for Simple Solidity Smart Contract
Since all the blockchain technologies are looking forward to webassembly, its better to write contract which is fits in webassembly environment. But DAML currently uses JVM. Can we replace it to webassembly?
And whats the reason for using JVM rather than Webassembly?
We built a JVM based interpreter to be able to leverage the JVM ecosystem and the Java SDKs provided by many of the existing ledgers.
There is no fundamental obstacle to compiling DAML's core language DAML-LF to WebAssembly. As of 2019-06-20, support for this compilation has not yet been built.
I have a contract using a library. when I deploy my contract. I see that 2 smart contracts will be created.
are there any ways to reuse my library without recreating a new smart contract to the nets?