Ethereum from scratch – Part 1: Ping
ocalog.com
ocalog.com
As one of the 'killer apps' for ethereum is smart contracts, I'd like to see this explained in a 'for dummies' high level way, then decomposed into the finer technical chunks needed to make it happen.
a "smart contract" is a script that runs on a blockchain to execute terms and manage funds.
the problem is that the tools that you use to make these are basically garbage. you don't write fin-tech in what amounts to javascript y'know?
And I think that even beginners know that you can't trust users' input - you have to sanitize it. And under no circumstances you want to execute it!
But here it is the opposite, isn't it? You basically give users ability to run any code within your application (blockchain). And you give them very insecure, confusing and badly designed language.
To me it is an epitome of insecurity. It is like giving a shotgun to a child!
i don't know how to do this myself, mind your. to be broadly applicable the tech has to be accessible to people who would be writing contracts. a fucking professional using the state of the art for this shit has very little tooling support for checking that the contract actually operates in a particular fashion.
something like an SQL query planner that helps you write contracts
The EVM, which is what executes contracts, has a public spec. It's a bytecode machine and writing a compiler for it should be rather trivial compared to x86.
There are also several other languages you can code in and there are some code verifier tools that allow you to check if your contract is good.
The problem is that despite these tools existing, even if they are used, they are underused.
* Little to none "get up and running" time. Custom tools don't allow for that.
* Provide such tremendous value that it is worth overcoming the initial setup hurdle.
Right now, Ethereum has neither.
I was merely pointing out that nobody is being stopped from improving the situation, if it was as bad as some portrait it.
I completely agree that the tools and processes for writing and testing smart contracts need to improve.
If there is > 1,000 Ether in this contract address before timestamp x then send the Ether to the project lead, else refund all the users.
And they can include conditions about arbitrary information that is reported on the blockchain (weather data, stock prices, etc...)
And multiple people can sign these things. They really are like contracts.
The (non-fintec) example I often hear about often is a voting system. (See: https://github.com/stonecoldpat/anonymousvoting , here zk-snarks algorithm is introduced to ensure privacy)
Essentially anything that requires co-ordination between parties that don't trust each other over a piece of data (a balance of money, the tally of a ballot) is a perfect use case for smart contracts. But since there is cost to running it on these secure networks it is important that they remain O(1) or at most O(n) time complexity, which for these kinds of applications is often totally enough. (eg. if (the message is signed by the 'owner') { send the funds } else { throw })
Actually, I didn't mean to come across as defensive. I just like to nerd out about tech.
Once you accept the inherent craziness of the proposal, and go "Ok, this is crazy. What now?" you end up concluding that the future is going to be very interesting. It'd be worth investing some amount (that you can afford to lose!) in ETH on the off-chance that it doesn't suffer a major disaster. There are quite a few interesting applications for this technology, and historically that's been a pretty solid bet.
[1] https://media.consensys.net/an-introduction-to-lll-for-ether...
A poorly written smart contract that handles real money, on the other hand...
Yes, it's crazy, but it's also happening.
Solidity doesn't appeal to me because its goal seems to be on-boarding JavaScript programmers. But new languages that compile to EVM can be easier to use "safely" and you will see several of these in the next few years.
I'm really excited that a project to embed Turing-complete behavior in a blockchain has actually taken off. It's completely insane from one perspective, but completely awesome from another.
The interesting question is whether a language can be design which allows the important domain-relevant requirements to written down in an understandable way and also proved rigorously.
So far neither lawyers nor programmers have done a very good job of this in their respective field. Watching people trying to do it in both fields simultaneously sounds like popcorn time to me.
And huge swaths of activity where programmers have laid out clear deterministic expectations.
If you're saying lawyers have failed to specify the legal ramifications of All Possible Activity then... Sure. So? Even if Ethereum only works for one single narrowly defined contract, it could be immensely useful.
The question for me isn't "where could it fall short" but "where might it measure up?"
A web app might not touch real money, but a leak can still have real money consequences for the users.
Short of auditing the Solidity contract code myself, there's nothing I can do to protect myself from the hacks themselves because the very mechanism by which money is transferred is riddled with bugs.
This is mostly just semantics anyway - I'm just trying to establish that writing money-transfer software in a poorly designed language is, one way or another, worse than writing a web app in one.
- vulnerabilities can be used to attack users directly or through social engineering
- (rare today, but definitely a problem with C++ web apps) you can break through a hole in the app and pwn the whole server
100% bug free software is impossible! As long as they are written by humans? Their will always be bugs. Matter who is writting them.
You don't need to prevent all bad behaviors, just slow attackers down.
Of course sometimes they can get through the review process too, but you start having probabilities you can multiply to decrease the likelihood of losses.
Over time we'll start to have good defaults for how those checks work. For now it's the wild west.
Smart contracts by composition would be really nice. Like a compile to EVM lisp!
https://github.com/ethereum/solidity/tree/develop/liblll
https://github.com/ethereum/solidity/issues?utf8=%E2%9C%93&q...
how would you even get started for this kind of job? all of the ads popping up seem to be looking for somebody who already has significant experience
For example, maybe you like to quickly reimburse each other for dinner, but you won't or can't use Facebook Messenger payments, perhaps because some of you aren't on Facebook, or you're not in the US.
So you want to make your own little payments system. You might start with just setting up a simple server that tracks your debts, with a simple web app to log in and send funds. Suddenly it's much easier for you to pay each other!
Once that works, you realize it would be really neat to have group payments, where you can automatically split a dinner bill, for example. And then maybe you'll even want to kind of crowdfund your dinners, so that any of you can put up a request that says "please send me 5$ each until tomorrow at 4 and I'll order food." You can see this becoming more and more complex.
This is kind of the evolution of blockchain going from simple transactions towards arbitrary smart contracts.
A contract on Ethereum is basically just an address that's associated with a little script in a stack machine bytecode. When you send a message to such a contract, you're actually signing a transaction that says "I hereby perform the instructions of this contract with these given parameters."
For example, the bytecode of contract X might be:
VALUE 2 DIV DUP <address-1> SEND <address-2> SEND
So this contract, when transacted with, would split the ETH value sent to it in half and send to "address 1" and "address 2".
The neat thing about this blockchain thing, compared to a Messenger-style central server, is that you can federate the service in a P2P way, so several of the friends can run a node that verifies all the history, and nobody needs to be trusted with an admin password that can change history.
The neat thing about having those smart contracts on the blockchain instead of as proprietary code is that each participant can (in principle) look at the contract's definition and know for sure what it does, and the contract can't be changed arbitrarily.
Let's think about your example and what it entails.
So you're going to a pizza party with your friends, and instead of saying to your buddy Mike who you're about to see in person and share some pizza with, "Hey Mike, here's 5 bucks, thanks!"
Instead you fire up the ol' ethereum whizbang machine, and "pay" Mike. The payment then rattles around the ol' globally distributed whizbang machine, at the SPEED of Light! powered by electricity through countless microscopic electronic gating mechanisms before finally settling into the storage media of thousands of computers around the world, where it will stay, forever.
That seems needlessly wasteful of resources and expensive.
What it boils down to, is what is this good for?
While some may have been, not everyone was confounded by the introduction of the web. Many could see obvious avenues of potential and development.
Even back in the 60s or 70s people were envisioning computer network enabled home shopping. Not sure many were envisioning a global distributed turing complete whatchamacallit with ever expanding resource needs because of no garbage collection by design.
So simply, what's the point? What do you do with it besides buy pizzas with your friends? How is it better than existing methods for doing whatever you envision doing with it?
What if anything, does it enable that would otherwise be impossible?
I mean, like, within three years you'll probably be having a virtual reality pizza party with your friends on the other side of the world. That's less wasteful of resources than flying, you know! And how will the money work? Maybe with a blockchain.
Let's try to stretch the imagination even more! Imagine you are involved with an open source project. You want to be able to receive some donations, collectively. So you briefly consider setting up a PayPal account, then giggle. "Ha-ha! Why would I use PayPal when these smart contract blockchains technologies have been working well for many years?"
So instead you go to one of the future's several competing smart contract platforms, and you click "Set up budgeted donation contract." It asks you to input the parameters for your donation contract. Maybe you end up configuring something like "Every week, this account's balance will be allocated as follows: 25% to GitHub; 50% split among these N core developers; 25% to the fund; and 25% to the EFF."
Your fans and users can then verify the behavior of this donation contract and easily contribute to your project! Wow! So much cooler than PayPal!
How is it better than existing methods for doing whatever you envision doing with it?
What if anything, does it enable that would otherwise be impossible?
So you've got nothing?
"Ha-ha! Why would I use PayPal when these smart contract blockchains technologies have been working well for many years?"
So instead you go to one of the future's several competing smart contract platforms
Simply positing a future scenario is not an argument for it's likelihood.
Why do I need a massively parallel system with enough energy to power a city to do this when I could just do it manually, or write a script to do it and run it locally? If one of the donators doesn't trust me or my code, then they can just donate to wherever directly.
I don't even get your scenario, what value is there in me/my contract being an intermediary between my fans and these other organizations? (and isn't GitHub a for profit company? Why would you donate money to them?)
Since you immediately reject my examples so completely, I think I won't persuade you. Good for you -- I won't fool you into wasting your time on this obviously pointless blockchain thing.
Maybe, you'd like to address the questions I raised and points of logic I made rather than the snark.
1. Payments and value management on the internet currently suck horribly compared to what you could imagine. (Insert your own imaginations here, since you don't like mine.)
2. Some attempts are being done to make payments and value management on the internet more convenient, but they are controlled by central authorities -- Facebook, Apple, Google, Twitter, Amazon, whatever -- so they will exclude, censor, limit, and control. (Just like Twitter controls your API access, Facebook forces you to use your real name, Amazon surveils your preferences, etc etc etc.)
3. Blockchains are the only way I know of to do this kind of thing without that kind of central authority, in a thoroughly open source way.
4. I can quite easily imagine a future when blockchains make it very convenient and nice for individuals and organizations to do payments and value management on the internet, in various creative and interesting ways.
Bonus point:
5. Resource use is indeed something to consider. (That also goes for, like, why are we using so many torrent boxes to seed Game of Thrones? Kinda useless! Stop wasting teh energies!) It is indeed also something that is being very actively considered by leading blockchain developers; for example, it's the major project that Vitalik Buterin is spending his waking hours on, in the form of scaling through proof-of-stake. There are highly functional versions of proof-of-stake already working for years, notably BitShares and Steemit, but they use a form of delegated voting that the Ethereum community mostly doesn't want.
Alternatively, the banks or payment companies are a series of non-profit foundations with protections or basic rights of customers built into their charter using regular, efficient databases with zero or low cost transfer between them. You pay a small, monthly fee to participate with your specific bank which may be waived if you do a lot of business with them. You get regular statements authenticated by the bank's HSM w/ hashes of those posted in one or more trusted, timestamping services for event bank's records are lost. Any major changes to practices might receive a majority vote by customers or people representing them from a diverse background.
So, basically traditional banks with legal incentives to not do bad stuff run by people whose background is pretty trustworthy. Many examples exist of coops, credit unions, and nonprofits that take care of customers due to good incentives. The admin overhead is kept lean per charters. The tech is vastly more efficient than proof-of-work-type schemes since it's just database transactions. Better cost/efficiency than before since new banks aren't stuck on expensive mainframes. ;) What you think?
Assorted banking use cases, trade settlements, payments to notaries, voting systems, vehicle registrations, wire fees, gun checks, academic records, cataloging ownership of works of art.
The Ethereum alliance contains many big name companies such as Mastercard as Cisco [1]. They all believe there is real use in Ethereum
[0] http://www.goldmansachs.com/our-thinking/pages/macroeconomic...
Smart contracts fit really well for generally managing securities, developping auto hedging portfolios.
Hey, that was an example meant to explain difficult concepts through terms most people will be familiar with. You can't judge it like this.
Somewhat related, and maybe I'm revealing my stupidity here, but I wish someone explained securities to me in a simple way.
A security is a fictional asset used to represent higher level operations one can conduct on an underlying asset. Basically it's all the made up tradable assets.
The specific definition varies depending on jurisdiction but if I remember correctly the SEC goes with something like any token that is used to transfer unrealised value between traders or across time.
About your example, I understand that but I'm sorry to see that all examples we collectively come up with for smart contracts are even more constrained than hello worlds and in my humble opinion unfit for the "real purpose" of the EVM. The same line of reasoning applies to bitcoin: it's not a wallet to pay your coffee or receive your salary, but an alternative to banks/payment processors when you need it.
Likewise in my opinion again, the EVM isn't made to replace informal contracts or legal/notarial/... affairs but to provide an alternative when the costs/benefits of contract law aren't fit for your use case.
> I understand that but I'm sorry to see that all examples we collectively come up with for smart contracts are even more constrained than hello worlds and in my humble opinion unfit for the "real purpose" of the EVM. The same line of reasoning applies to bitcoin: it's not a wallet to pay your coffee or receive your salary, but an alternative to banks/payment processors when you need it.
Fair enough, though I think that we need both, and preferably together. Those trivial examples are actually useful to people the very first time they try to understand the basics of cryptocurrencies and smart contracts. And after that, when someone gets the basic mechanics of the process, I think an example should follow with a description of actual use, and how the same mechanics facilitate it.
> Likewise in my opinion again, the EVM isn't made to replace informal contracts or legal/notarial/... affairs but to provide an alternative when the costs/benefits of contract law aren't fit for your use case.
I agree, I see it this way too. I cringe when I see people hopeful for replacing legal system with ETH, because that would be just plain dumb. But an alternative option to use when it fits better? I'm very much in favour.
What about another use case that's also fairly mundane but is date/time triggered and has a slightly different result/outcome?
Say someone wants to use ethereum to manage the sending of a bunch of birthday cards to friends.
Is it possible for an ethereum script be set up to trigger an event on a specific day to send a pre-composed email along with some funds (e.g. bitcoin or ethereum).
So, for example, with crowdfund contracts that have an expiration time, you would typically just make it so that after the expiration time, if the crowdfund didn't succeed, then everyone can reclaim their funds. They aren't refunded automatically; you need some user action to trigger anything.
It would be possible to have a single "refundEveryone" method which would send all the funds to everyone when anyone called it. But if there were thousands of participants, this function would be expensive to call, and possibly even too expensive for the network's limits.
The standard solution to this limitation is that you just have to incentivize people to call your contract at the right time. So you can for example make it so that whoever is the first to call the contract after the deadline gets a reward. Then you publish that and hope someone will do it.
(A simpler solution is to just run a cronjob on your own computer...)
How big can be the parameters? Megabytes is possible?
The problem is trust. It's helpful to remember that all the participants in an Ethereum network are adversarial. It doesn't matter how many bad actors there are as long as >50% of participants agree on the outcome. (This is a simplified explanation -- the real system is transitioning to proof of stake rather than proof of work.)
If you allow solidity to access the internet or the system compilers, you can't guarantee determinism anymore. For example, if you increment a counter by the result of accessing https://some-value.com (which returns a JSON value), you could program it to return a different result for everyone who accesses it. None of the nodes would agree what the true value of the counter should be. It'd also result in a central point of failure.
These same problems exist if you let Solidity access the system software. You could program it to give different results, so no one would agree.
The innovation of Solidity is that it's a set of operations where no matter what you do, the majority of nodes will converge to the same answer.
Does the EVM prevent this in some way?
I did some searching but I'm not sure I know what to look for either.
Moreover, a point that was not made clear to me when I first read about Ethereum, the programs are inherently limited in the number of steps that can be run, and the VM monitors this and terminates the program prematurely if it exceeds the limit. Moreover, longer programs cost the caller (the person or other contract asking the network to run this program) more money.
If the connection to the third party service is cryptographically secure, the Oracle can even provide proof the results were not tampered with, and if multiple data sources are used it can provide a consensus answer based on them.
Otherwise, the smart contract only has access to what is in the blockchain, but Oracles are pretty easy to write and use.
So far a few states (US) have passed laws regarding "blockchains", "smart contracts" and the like. For example, seeking to avoid any legal uncertainty surrounding blockchain transactions and smart contracts relating to certain digital assets, Arizona passed HB 2417, the following on point:
- A very specific definition of “blockchain technology” as a “distributed, decentralized, shared and replicated ledger, which may be public or private, permissioned or permissionless, or driven by tokenized crypto economics or tokenless” and provides that the “data on the ledger is protected with cryptography, is immutable and auditable and provides an uncensored truth.”
-A definition of “smart contracts” as an “event driven program, with state, that runs on a distributed, decentralized, shared and replicated ledger that can take custody over and instruct transfer of assets on that ledger.”
Other states in various stages of legislation on point include: Maine, Illinois, Nevada, Delaware and Vermont.
interesting notes: Arizona also passed a seperate law restricting the use of blockchain as "fire arm tracking technology", likely a pro gun rights lobbying effort. Delaware will likely be codifying by statute the right to issue stock on blockchains. Courts have begun accepting blockchain entries as business records under the rules of evidence.
If you could program money, you might not really need insurers anymore. You could just program insuree's money so it redistributed appropriately in case of flooding (for eg). No need to give you money to an entity and have a conflict of interest with your insurer.
Smart contracts are ways to program money by sending it to special addresses. These addresses contain a script that will decide how to redistribute the money. It's like if you insurance was a program.
That's an interesting way to think about it, but how do you communicate to the program that a tree fell on your car and you need it to give you money for a new one?
Basically what's the mechanism for communicating certain cases or conditions to the program, how does the program verify the claims you make to it, and how many of the scenarios where that works are practical for any real world applications?
IMO Smart contracts are a good way to model and trade securities, options or futures instead, leaving the underlying assets to be managed by real world humans who can make things happen out of the blockchain.
The incentives could be set up such that the cost of being caught straying from protocol would be higher than the fraud opportunity.
Or you could just reply on network-of-trust. Brand loyalty, etc. Choose Aetna claim investigators! We Follow Protocol
https://steemit.com/ethereum/@decentralised/hello-world-revi...
Hope you enjoy the post. If you have any constructive criticism you'd like to give regarding either the post or the website, let me know!
Unless you're a seed user (first 1000 people who sign up), then you don't have to subscribe to view non-free posts.
https://github.com/Roxxik/ping_ether/blob/master/src/main.rs
Looking into ethereum related stuff I often get the feeling that one already needs to know half of ethereum quite decent to learn something new, which makes it hard to even get started.
Reading your guide (am not finished yet) gives me a better picture of the things I actually need to do, to start discovering some nodes, so I'm really thankful for that and hope for more beginner targeted ethereum content.
See "OWASP top 10" for getting started with web security.
I tried to signup but ended up with a 500 error.
Too bad.
Edit2: You should be able to log in now.
- [ ] add edit view
- [ ] add autosave
- [ ] add comments
- [ ] add subscribe button
Which includes a few trillion dollar industries.
[1] http://www.javamagazine.mozaicreader.com/JanFeb2017#&pageSet...
This caught my attention: "In the EndPoint specification, it demands the "BE encoded 4-byte" address, which is exactly what's outputted by self.address.packed."
Does this mean that Ethereum only supports IPv4?
I searched around and only found this, dating back to 2014: https://github.com/ethereum/wiki/wiki/IPv6
"bytes address; // BE encoded 4-byte or 16-byte address (size determines ipv4 vs ipv6)"[0]
It seems that the user registration emails are causing a 500 server error and I'm working on a fix.
Edit: I'm bypassing the email confirmations for now, if you got a 500 error, please try to login using the account you signed up with. It should work, otherwise email me at mflynn210 <at> gmail.com.
Basically, there were a lot of blind spots in the official documentation and it took me a while to figure out things like how to make a proper key recovery id or which endianness to use where in the messages.
How far have you been able to get to? I still can't quite wedge into the mainnet - the nodes keep disconnecting me for unknown reasons some time after, and finding a new node to connect to takes a while.
My node does works rather well on the ropsten testnet, however.
Ah, I knew someone was going to get me on that. They actually give you the encode function in the specification. It's pretty straightforward and if I was to write it, would end up the same, so I decided to just import the library. But I agree it does go against the "from scratch" title a little bit.
> there were a lot of blind spots in the official documentation
Totally agree.
> How far have you been able to get to?
I'm actually trying to get the mainnet nodes to talk to me as well.
Bitcoin and Ethereum have very different intended use cases, as this article demonstrates. You could argue that Ethereum could be a threat to Bitcoin, or coexist, depending on your perspective.