If smart contracts are completely open source and viewable to the public, then what stops someone from copying someone else's work to create an exact copy of their service? Is the value a blockchain company can provide completely tied to the UX/UI of their application using a smart contract?
I'm thinking of a company like this (https://www.wageth.com/contract). The code is viewable on their site and they make a small profit by taking a cut of the prize pot that people contribute to. From what I understand, there is nothing stopping a competitor creating an exact copy of this game while routing the profit to a different wallet or account?
For this specific example the value of the organization is based on the brand loyalty of the users, the number of users, the fees, and addition of new features as new games are started. While the contract is open source, if you were to copy the source and deploy it on the ethereum network yourself, it would have a very different address and you would have to convince people to use your contract over the creator's. You would either have to offer lower fees, build a better brand, add more features or do better advertising. Similar to other markets.
The contract listed above "needs" to be open source because it adds a layer of transparency to the game. The maintainer(s) need to assure the participants that the contract functions the way they say it does and the best way to do that is to publish the contract source.
You could take the contract from your example and deploy it on a test network, verify that it functions as described and then participate in their deployed contract. Keep in mind that open source doesn't always mean free to use. If the contract is not published with a license that gives you permission to copy or deploy it, you likely don't have the legal right to do so just because they published the source code on line. (I'm no lawer)
Not all contracts need to be open source, while the compiled bytecode is stored on the chain, the source is not. You could copy the bytecode of a deployed close source contract and redeploy it. However, not being able to provide the source or possibly not having a full understanding of how the contract works could make it difficult to convince users to use the contract at the address you deployed over the "official" deployment.
Related
Recently I have been working on a class project. I have built a Supply chain Dapp, that was based on truffle framework and ganache as a local blockchain. I have some issues regarding the concepts of private Ethreum blockchain.
My question is, is it possible to build a real-world private Ethereum blockchain for a specific organization without any transaction fees and what other costs should I be aware of? And the second question is do I need to deploy my Dapp on Rinkeby? It's just that I read somewhere that you should deploy your dapp to testnets like Rinkeby to demonstrate that it functions well in a setting more like to the Ethereum mainnet.
Since I just used ganache for the dapp, I wanted to be certain
I found some answers online but they were not satisfactory, it would be greatly appreciated and helpful if you could provide me with some directions on the subject, as I am relatively new to this. Thank you.
Yes you can. These are generally called permissioned chains. While you incur compute cost, your org or anyone given permission to use the chain doesn't pay for gas.
There is still a gas price, it is essentially useless since as the authority on the chain you can mint infinite gas. Such chains usually have PoA (proof-of-authority consensus).
You can use these clients to build such chains:
GoQuorum - geth fork which lags in upstream updates by a few months. Has lots of consensus algo options like QBFT/Raft. Additionally ships with privacy tx manager. Application level permissioning.
OpenEthereum (Deprecated) - My personal favorite. I have worked with this client extensively and wrote a public humanitarian chain spec with it (https://github.com/grassrootseconomics/kitabu-chain). Uses AuRA consensus. Well documented.
Nethermind - Supports AuRa consensus. Haven't used it, but should have more features than OpenEtherem.
Geth - Supports Clique. I am not a fan of clique consensus but it can work well.
I have documented some PoA consensus comparisons here. You might find it useful.
My question is, is it possible to build a real-world private Ethereum blockchain for a specific organization without any transaction fees and what other costs should I be aware of?
No, because each transaction will consume CPU, IO and network bandwidth. These must be measured and the transaction stopped, or otherwise, one malicious transaction can halt the whole network by consuming all the resources. Thus, at least an internal unit of accounting is needed.
And the second question is do I need to deploy my Dapp on Rinkeby?
Why would you do that? Please read xyproblem.info on how to ask more understandable questions.
I understand from your question that you built a Dapp and tested it using Ganache and Truffle frameworks. However, you wish to test your application on a testnet similar to rinkeby.
It appears that there are certain projects which allow you to create a mainnet fork. You just need to provide them with the infura URL of the mainnet, and they will spin up your local Ethereum mainnet fork. This enables you to test your dapp under mainnet conditions. Additionally, you may assign as many tokens as you wish to your address.
Here is a link to a repository that can perform this task.
https://github.com/yearn/yearn-mainnet-fork
To deploy your contract on the local blockchain instance, you will simply need to use the RPC URL provided by this repository.
Yes, you can indeed.
Both GoQuorum and Besu allow you to create a completely gas-free network.
https://consensys.net/docs/goquorum/en/latest/concepts/free-gas-network/?h=gas
I'm new in the blockchain community, and i have to realize a web 3.0 project.
In this project, we have an ERC20, and for each user who sign up on our platform, I have to create a custodial wallet attached to this user.
User A want to be able to send tokens to User B.
I didn't find something concrete on google... so I'm maybe going in the wrong direction.
My question is: Is it possible to do that type of custodial wallet with smart contract in Solidity, and can you explain me how ?
In other to achieve this you will need 3 smart contracts:
Factory: This is the smart contract that has a function deployWallet that can only be called by a certain address, most likely the deployer address. What this does is deploy a new instance of another contract WalletProxy and store the address in a mapping to a UUID string which you use to identify each customer in your off-chain DB.
WalletImplementation: This contract holds the action you want your wallets to perform, e.g transferERC20, stake, swap, etc., and can be anything. It's going to be a contract you can always swap out and use another one with a more updated function, but be careful you need to understand how upgrades work in smart contracts and design Version 1 well. This contract will only be deployed once for every new version created.
WalletProxy: This is the contract you deploy every time a new wallet is created by calling the deployWallet function in the Factory.sol contract, only callable by a certain address. It serves as a wallet for each user and it's only a proxy contract that uses delegatecall to call functions from WalletImplementation, so in the future, if there is any update like WalletImplementation V2 it will always have access to it. The tricky part is also writing it in such a way that only a certain address can call all of the deployed wallet proxy contracts.
Reference Contracts:
I created the following contracts for the same demonstration purposes when asked how to create a custodian wallet using smart contracts.
Factory.sol
WalletImplementation.sol
WalletProxy.sol
I also did a live session where I built a simple exchange using the pattern described above. You can also go through the full codebase here https://github.com/CeloTAs/cXchange
I'm documenting in this blockchain world. Basically I would like to make some web application in which a user decides to make a donation, and would like to see who made the donation and to which entity. I have several doubts, the first one:
1-Is it possible to use blockchain using javascript? (can smartcontracts be done in javascript?)
2- If the donation is made using blockchain, is it necessary to use a cryptocurrency? or you can use real money and make the transaction (using some means like paypal)
3- Can real money be transferred by some means such as paypal using blockchain?
Thank you very much, your answers will document me much more
Is it possible to use blockchain using javascript? (can smartcontracts be done in javascript?)
Every blockchain has a SDK, the part of the software which lets you
interact with the real blockchain( A decentralise ledger). There
are generally two parts in the Blockchain , One is client and one
is processor.
As you must have guessed, Client is the one who sends the transaction,
This transaction must satisfy certain rules in order to be accepted by
the transaction processor. If the transaction gets validated by
transaction processor, The transaction will be added to the block alongwith
other transactions and this block will then be added to the blockchain.
Copied to all other nodes (Forks are a different story)
Generally Most blockchains lets you interact with the blockchain through
ABCI which is just an interface to convert your transaction into
a format understandable by the blockchain processor.
Some blockchains has their fixed transaction processing logic like Ethereum for
security and some lets you write your own transaction processing logic like
Sawtooth, Fabric etc.
Permissioned and some public blockchains like Hyperledger projects and
cosmos SDK lets you write your own application layer logic for Blockchain,
So yes, You can write those transactions in Javascript or any other programming
language, as long as it satisfies the interface.
Public blockchain deals with tokens having real worth. Their transaction logic
is already fixed, but some of them does provide javascript API's like NEO
(Not sure about that)
2- If the donation is made using blockchain, is it necessary to use a cryptocurrency? or you can use real money and make the transaction (using some means like paypal)
You can do that and put the donation receipt on Blockchain linked with
real identities of people. This way if anybody wants to check who pays
how much donation, They can query blockchain for the user address.
3- Can real money be transferred by some means such as paypal using blockchain?
This can also be done, but this will involve using a crypt exchange,
centralised or decentralise. You can convert the real money into crypto
of your choice at one end and vice versa at the other hand.
Note: This is based on my limited knowledge of Cryptocurrencies. Please consult more people or any professional company before acting on this advice.
I don't think any protocols offer the possibility to implement their smart contracts in Java Script, but you can build a translator between the two languages which could potentially benefit others in the open source community.
So you want have some engineers do some work for you, in this case build an web application. There are several ways you can get this done, here are some ideas:
a) issue tokens which pays profits based on the success of your new business, you might be able to do this on a protocol that is not tied to any specific crypto or fiat currency.
The users can use an exchange to convert your tokens to their favorite one.
b) approach a private equity or VC fund and get them to pay for it.
c) forget about blockchain, and just pay for the project to your favorite engineers.
Recently I made a block-chain (ethereum) application using Nodejs , express ,Solc. where I have a owner, renter and some Object to be renter.
My concern is either should i make one universal smart contract using for all the attributes or should i make a 3 contracts individually.
As i have observed in remix IDE the total transaction cost in 3 contract is lower than the one contract.
Can you please suggest which is a better option?
You have to choose an option which works. I would always separate contracts when I can. Just because it's blockchain and deployed contract cannot be changed later. Imagine the situation when you made a mistake in one contract but deployed all 3 as one. You will need to redeploy all your contracts which is disaster. And finally as you said, 3 contracts are even cheaper, so why are you still asking? ;)
Basically it's like uniting 3 web application into one monolith application vs having couple of services. My experience in web tells that services wins :)
I am learning blockchain technology. I read many tutorials and I got the basic idea of what blockchain is but I am confused with the fact that are there individual separate blockchains for separate DAPPs and the people who are using that DAPP, will only be the part of that DAPP's blockchain and what the blocks in Ethereum blockchain really contain ?
If anyone can clear my novice doubt, that would be very helpful.
Thanks in advance :)
A dApp, which is a decentralized application, may or may not have it's own blockchain. It depends.
For example, there's the Ethereum mainnet, which is public, and anyone can have their dApp interact with it. In this case the dApp doesn't have it's own blockchain.
However, anyone can fork or run their own copy of Ethereum, which in this case, it's a separately owned blockchain instance so it'll have it's down data and blocks not pegged to the public mainnet blockchain.
A DApp is a decentralized Application. This is usually a set made of:
a smart contract (your backend if you like)
some web frontend to interact with it (UI)
A specific smart contract is deployed on one or several chains. It depends what the author decided to do.
Regarding your frontend, you could implement it so it can interact with your smart contract on all the chains you support.
So if your smart contract is deployed on mainnet + testnet for instance, you could write your frontend to support both.
So a given DApp may support multiple chains but an author may also decide to write different Smart Contract + UI depending on the chain it is supposed to run on.
The most basic DAPP you'll write is a (javascript) frontend with a single Smart Contract stored on Ethereum as the backend. A Smart Contract is a Robot Account. It's a regular account WITH code AND storage.
When a transaction hits the Robot Account, the "Ethereum Machine" will start the robot and run its code. Maybe the robot will write to its storage, start other robots, etc. But this is still part of "THE" Blockchain, because it's just a transaction. Slightly more complicated than "move X$ from A to B", but still a simple transaction with a source, target and payload.
There's ONE Blockchain on Ethereum, it's a chain of Block. And a Block is a list of transactions. And a Transaction is a source, target and payload.
Once you start writing more complex DAPPs, maybe Ethereum won't be sufficient anymore. Maybe you need to store large files which is too expensive on Ethereum. That's where you may use other PLATFORMS, that are going to use their own Blockchain.
If you want more implementation details, checkout the Ethereum Yellow Paper:
"The Transaction" is described in section 4.3
"The Block" is described in section 4.4.
Each Smart Contract have their own Merkle Patricia Trie which ressemble a Blockchain but it's more of an implementation detail.
I wrote in more details about how Ethereum Storage works with gas & cost considerations & why you may want to use something else, I hope that can help you.