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?
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
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.
Just started with NServiceBus and I am trying to understand how the bus fits into my VS solution.
Let's assume an existing application, that has an ASP.Net front end and a BLL. I am using Windsor for DI and my BLL has no knowledge of the container. I wire the container up in a separate project I call "MyNamespace.IOC", and only this project and my web project have knowledge of Windsor.
I need access to the bus in my BLL (since that is where I will be sending/publishing/handling messages). I need to configure NSB using Windsor, and (I think) pass an instance of my container to the Configure.With().CastleWindorBuilder() method at app startup.
It seems odd to have all three projects have reference to the NSB DLLs. How does one normally wire this all together?
If you do not want to reference NSB in your BLL / domain layer you could have a look at 'domain events'. The domain event handlers can sit in their own implementation layer leaving your domain ignorant of the handling of the events and, therefore, requiring no knowledge of the service bus. From there you could publish your esb messages. It may not seem like much of a difference but the domain event-handling layer is more isolated from the domain.
Just as a side-note: since you are starting out with a service bus you could also have a look at my FOSS project over at http://shuttle.codeplex.com/ --- any feedback would be appreciated :)
You can abstract bus behind some interface and provide the implementation only in IoC and Web projects.