When speaking about Ethereum, smart contracts and decentralised exchanges a term non-custodial is often used. What does non-custodial mean in the context of smart contracts and exchanges?
Non-custodial is opposite to custodial where someone else has custody of your assets and can decide what to do with them. For example, in a centralised cryptocurrency exchange, the exchange operator can do whatever they want with your deposits. Because of trustless nature of cryptocurrencies, insider fraud and hacks rampart with custodial services. Other custodial risks include bankruptcy, unavailability (offline) and regulatory risks (shut down because of legal unclarity).
Smart contracts can be designed to be non-custodial. No one has a master key that would make trades, transactions or other actions to go one way or another. The transactions are solely governed by the laws of smart contracts. No human can change the outcome of the contract.
When the contract rules are written as the smart contract, its non-custodial nature makes smart contract-based of services less risky than custodial services. Whereas custodial services always have a counterparty risk from its operator, smart contracts do not have this risk.
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.
I'm a product manager not a Blockchain coder, looking for a 2nd opinion and some general good practice advice. I have one question in bold, the rest is background.
Background:
We have an app in development that will write user's information into a Smart Contract on the ETH blockchain.
The SC's we deploy contain information only, no Ether.
Each user has their own SC which stores only that users specific information.
Our App allows the user to edit and update this information and then upload the changes, encrypted, into their own SC.
The user's SC address is 'tied' (sorry for lack of correct terminology) to their own Ether wallet.
I see on Etherscan (Ropsten) there is a Contract Creator address which is a constant for all the SC's our App creates.
I'm assuming that the contract creator address is unique to us, it is code we've created and as such it deploys only our Smart Contracts on behalf of our Application.
I was hoping that each SC address would be known only to its owner and us only. Now I see that anyone can access this information.
My Concerns:
Should there be an exploitable flaw in our code then a bad actor has a list of contract addresses to attack.
The worst-case risk to us is that a bad-actor could access each users data in an unencrypted state if a flaw exists in our publicly accessible code.
The Bad-Actor then uses that flaw and the list of smart contract addresses they can get from Etherscan to download multiple users data.
My Question
Are these realistic concerns?
If so what general directions can we look at to mitigate these risks
If so is there a way I can obscure the Creator address in Etherscan without other negative consequences
The developers are outsourced 3rd parties and excellent people to work with. But Im looking for an alternate opinion than just theirs at this time as a double check.
Apologies if the information Ive provided is confusing or incomplete.
Thanks in advance for your time.
I was hoping that each SC address would be known only to its owner and us only. Now I see that anyone can access this information.
As you have addressed here, data regarding the blockchain (i.e. transaction hashes, contract addresses, and user addresses) is transparently available. This is by-design with Ethereum and allows for the traceability aspect of the ledger.
Furthermore, smart contract data is potentially available to any actor in the Ethereum network. However, that is based upon the following:
In order to access the smart contract data, an actor would require the contract ABI. This interface allows code to be written to interact with the smart contract methods. Now, it is helpful to understand that this ABI could hypothetically be easily reverse-generated with enough details of how your DApp interacts with the existing smart contract.
If your smart contract logic has exploitable flaws, a malicious actor on the network could take advantage of this. This is why contracts should be well-written and unit tested with near (if not) 100% code coverage. You should also identify the potential actors in each contract scenario and be sure your test cases appropriately cover these scenarios.
If so what general directions can we look at to mitigate these risks
Given the contract scenario you have described, if the only actor who should have access to these user data smart contracts is the user them self, then you simply need to apply something akin to a function modifier to your smart contract logic. In the linked example, access to the smart contract data is restricted to a single specific Ethereum user address.
If so is there a way I can obscure the Creator address in Etherscan without other negative consequences
Sure. It sounds like you're currently using a single account to deploy the smart contracts, hence the creator address is constant. (Side note: I'm not sure why you're deploying the contract on behalf of the user with this account, it sounds like the user should be deploying their own smart contract). Regardless, you could simply create a new proxy user address each time you deploy the smart contract. However, I don't see any benefit to doing so and this would just be an example of security through obscurity.
How can I update the smartcontracts of my Truffle dapp which are deployed in the Ethereum blockchain?
Great answer found here.
From axic in Ethereum Stack Exchange site:
Contract code is immutable, the storage is mutable, but you cannot
execute code placed into storage, at least for now.
Bugfixes to contracts
As for bugfixes, the common pattern is to have proxy or lookup
contracts to be a gateway to the real one, which in case of a change
or bugfix would be replaced. Replacing it also means losing the old
storage contents.
Keeping storage
If you want the ability to upgrade code, while keeping storage, you
could think of separating storage and logic. Have a dedicated storage
contract, which accepts write calls from trusted addresses (e.g. the
logic contracts). All important storage should be associated with this
one.
Accessing storage after selfdestruct
As of today there is no real pruning implemented even in the case of
selfdestruct, but that should definitely come in the future. There are
several EIPs discussing this.
Even if pruning is implemented, it shouldn't happen in an instant and
you should be able to read storage from the last state. It is also
planned to have archive nodes to keep states indefinitely -- not sure
that is feasible without limitations just by judging at the growth of
the blockchain.
Redeploying at same address
In short: practically this is not possible. The contract addresses are
calculated from the sender and the nonce. The nonce is sequential,
there cannot be any gaps and there cannot be duplicates.
In theory it is possible to arrive at the same hash with a different
nonce and address combination, but the likelyhood is small.
I have a copyright section in the contract I give to my clients stating that I retain copyright on any works produced during my work for them as an independent contractor. This is most definitely not intended to place arbitrary restrictions on my clients, but rather to maintain my ability to decide on how the software I create is licensed and distributed. Almost every project I work on results in at least one part of it being released as open source. Every project I work on makes use of third-party software released in the same fashion, so returning the favour is something I would like to continue doing.
Unfortunately, the contract is not so clear when it comes to defining the rights of the client in the use of said software. I mention that the code will be licensed to them, but do not mention specifics about exclusivity, ability to produce derivatives etc.
As such, a client has raised concerns about the copyright section of my contract, and has suggested that I reword it such that all copyrights are transferred entirely to the client on final payment for the project. This will almost certainly reduce my ability to distribute the software I have created; I would much prefer to find a more mutually beneficial agreement where both our concerns are appeased.
Are there any tried and true approaches to licensing software in this kind of situation? To summarise:
I want to maintain the ability to license (parts of) the software under my own terms, independently of my relationship with the client;
with some guarantee to the client that no trade-secrets or critical business logic will be shared;
giving them the ability to re-use my code in their future projects;
but not necessarily letting them sell it (I'm not sure about this, though...what happens if they sell their business and the software along with it?)
I realise that everyone's feedback is going to be prefixed with "IANAL", however I appreciate any thoughts you might have on the matter.
Create a license that grants the client the right to use and modify the software, but restricts distribution outside the organization the software is licensed to.
That should cover your needs, since you state in your contract with the client that you retain control over the copyright of the software, and they license it from you under a license chosen when the contract is signed.
As long as you also sign a NDA when you sign the contract, their secrets will be covered by that.
Edit: Oh yeah, almost forgot: IANAL
Try breaking the project into components with their own licenses. This way business logic has their copyright and generic components have your copyright and open source license.
After considering the two answers given, I decided that a combination of the two approaches would yield the best results.
With that in mind I have defined two types of deliverables; generic and client-specific. The client receives exclusive ownership of the client-specific deliverables upon final payment, and I maintain ownership of all generic deliverables. The client is granted a "perpetual, irrevocable, limited, non-exclusive, non-transferable, worldwide license, without the right to grant sub-licenses (except to affiliates and subsidiaries)".
This change satisfies the requirements of both myself and the client.