As per the near documentation, smart contract is deployed to the account - which is my wallet account.
How does this work in case of multiple smart contract? Is it possible to deploy multiple smart contract with the same wallet account and reference each of these smart contract in my product sth similar to Ethereum.
Execute scenario
Deploy a smart contract A with wallet account B
Deploy a smart contract C with wallet account B
Try to read the function of contract A. It throws error in Near blockchain.
In ethereum it works with smart contract address.
Q: Is it possible to read the methods of smart contract A with wallet account B?
As a follow up I explored it more. A smart contract is deployed to a near account. It means technically a near account can't have the more than one smart contract. We access the smart contract methods with <account_name>.method_name_of_the_contract
Maybe I´m not understanding the question right, but the answer is:
Yes, you can read the methods from a contract with another wallet.
Even you can call those methods, you need to add the logic to your Smart Contract for avoid specific wallets or whitelist wallets if you´re making something private.
Related
I'm new in blockchain development, I wonder why is it necessary to interact with contract from another contract instead of from a personal EOA address?
Besides the delegatecall, I can't imaging any advantage to use contract to call another deployed contract's functions. As a user, I may rather use ethers or web3js through wallet etc to interact with a deployed smart contract instead.
would you please show me some reasons or necessary cases that I should design my project using a smart contract to interact with another smart contract? Thanks a lot!
There are too many use cases:
1- Upgradeable contracts or proxy contracts. Since blockchain technology is evolving so fast, it is so hard to write a contract that will be scalable. With proxy contracts, user calls the proxy contract but proxy calls the main contract. if in the future you have to change the logic of the contract, you deploy a new contract and make the proxy contract call this new contract. This way users will not get affected. You can read more about this pattern here
2- If you ever need to get data from real world, you cannot make an api call because this is not safe and not deterministic. for this reason, we use oracle services which also calls to many other smart contracts behind the scene, gets the results from each, and make a final response to the user. You can read more about oracles here
3- another use case is factory contracts. think about it as a class and users keep make an instance of it. that way instead of factory owner pays for the new contract creation, user will be paying for the deployment. you can read more about factory contracts
4- defi platforms have too many smart contracts and they are interacting each other. They keep the logic separate from each other, so they maintain better and see the missing points better. also putting everything in one contract would make contract code is bloated and make a mess. you can read uniswap
5- another use case to deploy library smart contracts. those are usually mathematical contracts which are deployed once and once u need complex functionalities, instead of you implement in your contract, you use library contracts and use them in your project. You can read about libraries
6- another use case is solving the scalability issues. imagine you have one kitchen and you have to serve all the customers from only one kitchen. As you get more customers, your service will eventually halted. so, there are layer 2 solutions to transfer some of the orders to different kitchens. and this of course happen through smart contract communications. more on layer 2
7- In general you can use inheritance. You deploy some contracts and inherit the logic from those smart contract. that is why you see openzeppelin contracts always inherit from each other
For example there are some standarts in Ethereum ecosystem. ERC20, ERC721, ERC1155 and others. So when you developing new project, instead of writing it from scratch you could install openzeppelin-contracts, import them and inherit. Afterwards you have this "carcass", on the top of which you can implement some additional functionality/custome code, etc. That approach is way more convenient and secure.
Another great example chainlink-contracts. Via them you can read from oracles. Oracles are smart contracts that keep track of cryptocurrencies prices online. Say you want your users to pay 10$ to participate in lottery/some giveaway. Your contract interacts with chainlink contract and makes sure that amount of eth that user paid is greater or equal to 10$ otherwise it returns error.
In solidity there is no true randomness, but again throughout interacting with chainlink contracts we can reach it. Another chainlink feature is automation contracts, check chainlink documentation to learn more(https://docs.chain.link/). To sum up id say that there is a lot of different protocoles/concepts which easier to interact with than to write it again.
"No need to reinvent the wheel"
I am learning about threshold signatures and their use cases on EVM Blockchains.
I am trying to understand how they are able to always have the same address.
Is the following correct? It is my understanding of how it works
A smart contract exists on chain. This smart contract is the address
of the TSS wallet. The smart contract has a function that decides if
signatures are valid. If this function is called with the requisite
(threshold) signatures from parties, it approves use of the smart
contract address for on chain meta transactions.
TSS does not have a way to work off chain to produce an Externally
Owned Address (EOA) even in a two party case. It depends on a third
party smart contract to authorize use of an address.
Sorry if I'm way off, it's quite hard to understand the underlying tech of TSS. As I understand it, there is no known way to create an EOA without re-assembling a private key e.g. with MultiSig right? Or can TSS produce signatures from the same address based on signatures of two parties, such that the TSS signature always represents the same address / private key that is not known by any party? Any examples or documentation would be greatly welcome!
I am not an expert on multiparty computing (MPC) which I believe threshold signatures (TSS) are part of. Thus, I do not know if there is a way to cryptographic natively to have a stable EOA for TSS. But I know some multiparty computing hardware companies do this by providing generic multisignature solutions across multiple different blockchains.
However you can have a simple threshold scheme with Ethereum by
Deploying a smart contract that lists its owners in the on-chain storage
The smart contract needs to have just one function to check if the incoming messages contains enough signatures from owners
The address of such account is the deployed smart contract address
Here is a tutorial of building such a smart contract wallet by Mahmoud Fathy.
How to deploy a smart contract on multiple networks and keeping the contract address same in all the networks? Please help me with this situation, if is there any way to do such .
Contract addresses are deterministic. They are formed from the senders address and the network nonce. So on different networks you would want the nonce to be the same (assuming you will use the same sender address across different networks) when deploying the contract.
However there is no real benefit of having the same contract address aside from maybe less verbose docs or maybe recovering lost funds sent on a wrong network.
Is it possible to transfer ERC-721 tokens from multiple wallets to a single wallet in one transaction? If not, is there another quick way? I'm interested as I mint a lot of tokens (50+) to multiple wallets, and want to merge these all into one wallet quickly. What kind of a smart contract would I need to write for this?
Is it possible to transfer ERC-721 tokens from multiple wallets to a single wallet in one transaction?
No it's not possible. You can always write your own ERC-721 token contract that supports such functionality. Normal NFTs do not desire this functionality as it only makes bot minting easier and bot minters is something the community does not tolerate.
Is it possible in Solidity for a smart contract to be able to interact with a specific wallet in such a way that it can pull money from it, and send money to it at any time it needs to? In this particular scenario, there will be a treasury wallet, that I want the smart contract to be able to pull from and send to at any time it needs to. Is this something that's possible with a few approvals, or perhaps is there a better, more standard way to resolve the problem that I'm having?
The treasury wallet needs to do ERC-20 token approve() on the specific wallet and then it can pull money.
For further details, check out EIP-20 spec.