DevCon IV, The Resurrection: Part 4

The lectures were interesting, but let’s not forget one of the most important purposes of the conference: to reconnect with old friends (of which I spent most of my time towards the end). And connect with new ones! Speaking of which, it looks like Microsoft has decided to move into the neighborhood, complete with their spanking new workbench:

They did a good job trying to sell it, especially for Ethereum users. For the grizzled developers like me, I appreciate that they’re trying to entice more of the enterprise people (i.e., oldtimers) to Ethereum by integrating existing platforms (like BizTalk) with the blockchain. I’m still not sure about their approach with BizTalk, and I still prefer my solution to their solution…but who knows? Maybe it just needs some time to mature.

It seemed like only a few more minutes passed by, but when I looked up at the board, it was practically over!

I could hear the singing that signaled the unfortunate end of the 4-day event. I couldn’t say what was worse: it was already finished for this year, or somebody still thought that it was a good idea to close the show with a sing-a-long in the style of Ned Flanders at Bible Camp.

Minus the singing, I’m already looking forward to next year!

Advertisements

DevCon IV, The Resurrection: Part 3

Of course, there were some events that I should have attended but did not (like the Buterin talk), but I lost so much time in conversations with people. Eventually though, on another day of the conference, I decided to pry myself from talking and follow one crowd to a lecture, as everyone poured into one of the larger lecture rooms. I wondered what this talk would be about…and then out walked Emin Gün Sirer! I had heard of him, and I knew that he was doing some work on Serenity…but, ultimately, being the newb that I am, I didn’t actually know in detail. (I learned later that he assists Buterin and others with ideas regarding sharding.) As it turned out, though, this lecture was more of an argument for Avalanche instead of Casper. So, what exactly is Avalanche? Sirer eloquently and amusingly put an end to my ignorance, as he launched into an explanation.

Unbeknownst to me (since I am, in fact, a newb), Casper wasn’t the only popular proof-of-work algorithm that was out there. Where Casper relies on disincentives in its trustless model, Sirer explained that Avalanche relied more on statistics and random sampling. Since all memories of my S&P 101 class in college were now holes in my brain chewed out by chronomice, I’ll admit it: I didn’t understand it completely. But I was still dubious since mischievous behavior wasn’t taken into account. Like Casper’s Vlad Zamfir had said: “We don’t get to take a probabilistic model of the network for granted [in my opinion].” In any case, though, it was an interesting talk, and I appreciated his passion for his project. He was confident, enough so that he even wanted to create a platform and token based on his work:

It was an informative and entertaining presentation, and he probably won over some people. Personally, it gave me an appreciation of the thriving competition for passionate ideas in this nascent community. More importantly, it showed me that there was an open-minded attitude here not often found elsewhere. Given that Casper has been the picked implementation for the next version of Ethereum, the organizers of DevCon could have shut out any dissenting opinions. Instead, though, they had embraced this alternate idea and had given Sirer a platform to advocate it. I now appreciated this whole movement on a grander scale.

Let’s hope that it will stand the test of time.

DevCon IV, The Resurrection: Part 2

So, after wolfing down a lunch of Czech dumplings from the ample buffet and walking past the Giveth guy (who I didn’t know at the time and just thought was wearing a bad Halloween costume), I headed to the talk by Golem, out of curiosity since I had no idea who they were. Plus, since we were in Prague, it seemed appropriate. And after a few confused minutes, I finally got it. Wow.

Basically, Golem was offering a secure platform that decentralized the notion of buying and selling cycles of computing power. Instead of AWS EC2 and Azure VM, you could purchase your power from anonymous sources around the world. And on the other side of the coin, you could become an independent vendor, offering your computers as computing providers on the network. As a vendor, you’d just install their software on your machines. Of course, one would think of all the possible questions about trust on such a platform, but it seemed that Golem had those bases covered.

And how does Ethereum fit into all of this madness? It’s the transaction-based layer of the platform, of course! All agreements and purchases would occur within the Ethereum blockchain. How beautiful is that: one decentralized platform supporting another! After that lecture, I was hungry to discover what other projects were being developed with Ethereum in mind. So, where to next?!

DevCon IV, The Resurrection: Part 1

So, the Ethereum conference this year lived up to its name of DevCon, unlike the “DeadCon” from last year. And the organizers couldn’t have picked a better city and better conference center for it!

Prague lived up to its reputation. What a view from the conference center!

And unlike last year, this year wasn’t about ICOs. It was about the developers again!

Talks and sessions about fundamentals was again back on the table. In fact, one could argue that there were too many options to choose from!

Even though I didn’t get to attend all of them, I did manage to sit for a few, which I’ll describe in subsequent posts. I’ll need the space just to summarize them!

I Always Start with a KISS

Most of the time in tech, you can stand on the shoulders of giants and reuse great works to your benefit, whether those things be algorithms or engineering methods. But, sometimes, as you venture towards the edge, you realize that you’re now somewhere completely different. You find yourself floating in some unknown ether, and you need to reorient yourself to this new dimension. And the more I play with the Ethereum platform, the more I find myself in that position.

For example, when I first started to create the Wonka rules engine, I had a few plans in mind, with one being to possibly use the Rete algorithm within the project. After all, it provides an efficient solution for a dynamic situation. Specifically, this dynamic situation could be one where a rule at the end might change the data, and then the whole set of data would need to be reevaluated by the rules due to that change. In this case, the Rete algorithm provides a performant method for this possibly recursive set of reevaluations. But that’s in the normal world, not the Ethereum one.

Within most standard computing, there’s minimal cost to using a system’s resources. At worst, you’re paying a cloud provider for cycles; in order to run a limited set of rules, you’re still talking pennies. But in a blockchain environment like Ethereum, where you have a massively distributed database of decentralized shared resources, every execution is an expensively coordinated effort. In order to change the state of the system, the cryptocurrency of the system, Ether, is used to cover the cost of a transaction, which is described as the ‘gas’. And even though the market value for Ether keeps sliding down, it still means that every rule that changes the system is another line item on your ‘gas’ bill. That’s difficult to predetermine since it’s always based on context. Yes, you can run your own private Ethereum blockchain within your own network (instead of the mainnet), and that means you’re not paying real Ether at all…but, in the end, people using blockchains generally still want accurate measures of impending execution.

Which brings us to the ultimate question for anyone using a rules engine within a blockchain like Ethereum: how much is this damn thing gonna cost me to run? Since the answer could be “a lot”, we have to abandon our beautiful, time-proven algorithms and go back to the drawing board. Which is why when you’re dealing with nascent platforms, you have to go back to KISS (i.e., Keep It Simple, Stupid). So, in this MVP version of a rules engine, I did just that, creating a straightforward implementation that just gets the job done. In this current state, its destiny will more than likely be as unwept, unhonored, and unsung. However, at the very least, such a prototype can be used by others to evaluate and perhaps validate the existence of a rules engine in this new space. And, maybe, just maybe, it can serve as the first iteration of something that will eventually become worthy of note.

On a side note, it turns out that getting a ticket to DevCon is a lot harder than I thought.

Quick Tangent: Can the Future Get Here Already?

For the most part, I tend to regard the idea of my ghost invasion game as simply vaporware…but every now and again, some kind of news comes out that makes me think on the contrary.

A device that can track people through walls? As a medical monitoring device, it has enormous potential. Of course, though, there are the creepy possibilities that could become the stuff of Orwellian nightmares…but for a moment, let’s ignore it. I’d like to think of the other potential uses for it…namely my game! So, Ms. Katabi, as much as I’m afraid of your electromagnetic Eye of Sauron, I can share your vision of its more benevolent usage. I only have one question: can I get a development kit before governments of mass surveillance become clients and raise the price?