This is the second part of my Decentralization topic, started with http://igorartamonov.com/2019/02/on-decentralization-part-i/, based on my presentation about a role of decentralization for a public blockchain.
In my previous article I’ve written about factors that could possible affect decentralization of a public blockchain. And if you start applying them to existing blockchains, it becomes clear that most of blockchains are guilty of one or two of such factors.
It’s much easier to sell centralization disguised as decentralization, and is very profitable. It seems that nobody cares about decentralization anymore. Maybe decentralization doesn’t even matter?
What is the problem?
What is the problem with centralization? It’s obvious that a Central Point is a Point of Failure, but what kind of failure in this case?
Any central point can be used to get some advantage. Control of a public blockchain is a power, which governments, big corporations and criminals want to control. Humans are weak point, they are especially exposed if they are part of that central point. Not necessary to destroy, but force them to do what powerful actor wants.
Most people think it’s impossible to force any changes, “because it’s Open Source”. Unfortunately not every problem is easy to notice, otherwise we wouldn’t have software bugs. Some backdoors can intentionally be planted in a code and pass all verifications, only authors would know how to use them. There are many examples of that.…
Last week at the Financial Cryptography conference I made a presentation about a role of decentralization for a public blockchain. Now I want to describe better my thoughts and position. I’m going to make few blog posts about it, this one is the first in the series.
If we will come to a decentralization metric from 0 to 100%, where 100% is fully decentralized blockchain. I believe that the average value for the top 10 blockchains will be less than 50%, likely less than 25%.
Most in the top 10 don’t even try to be decentralized. A centralized blockchain is a current trend, it is more effective for the most of the use cases and easier to compete in marketing, so most of the current blockchains are fine with being centralized.
If we speak only about the protocol, a peer-to-peer network, in most of the cases we have a decentralized network. That’s where people usually stop thinking about decentralization.…
Using ETCDEV issues with financing:
• DFG convinced me to give them access to the ETC Github
• DFG was unhappy that I was not going to agree to changes in the ETC core tech in return for them investing in ETCDEV
• Darcy Reno, ETCDEV’s Program Manager, was hired by ETC Labs/DFG and subsequently lured ETCDEV engineers to quit ETCDEV and join ETC Labs
• DFG copied all the ETCDEV code to their account on Github
• DFG took admin control of the ETC Github by removing all other admins
The past month has been very busy for us as we have been experiencing an attempt of a takeover of ETCDEV and ETC. My last post regarding our financing issues was a small part of that. I didn’t want to publish all the details at the time, but now it seems I have no other choice. I’ll try to summarize everything and make it as short as possible.…
Term Smart Contract is current standard name for a code deployed to a blockchain. Originally proposed by Nick Szabo, and later adopted by Ethereum Foundation. It may be a good name, but apparently it brings some confusion and I think changes the path of the industry.
For me, as non-native english speaker, it was just a term without any extra meaning. I mean we have a very rich terminology in software engineering, and for most of the people outside of english speaking countries nobody thinks about literal meaning. Similar to “San Francisco” which is a name of the city now, and I believe nobody associate it with a religious place.
I started to realize that there is something wrong with the Smart Contract term at 2017, when I noticed that when I talk to people in US about Ethereum they quickly switch to a discussion about legal aspects and agreements between people enforced on blockchain. It was even common to hear something like “Oh, it must be for criminals, [as they can’t use traditional court to resolve disputes]”. Em, what??
The problem that it influences how people think about technology use cases. Once they got into the box of a contract they can’t think outside of it. All the talks are about digital assets, finance, escrow, insurance, tokenization, binary options, logistics, etc. Even Ethereum Foundation, which were originally talking about “world computer” is more focused on tokens and ICOs now. There are not technology talks in blockchain conferences anymore. All talks about legal aspects, regulations, jurisdictions and so on.
While it’s fine to develop something related to legal contracts, it moves technology into one narrow path. There is nothing wrong with Smart Contracts, but it’s just a subset of all possible solutions that can be deployed to blockchain. Maybe other things can leverage decentralized computing? Honestly I don’t think many of contracts needs any decentralization, most of current tokens/ICOs are pretty centralized with a single switch right in a smart contract. But nobody cares, so [for a contract] a decentralized trustless ledger not a critical feature at all.
In 90s there were a lot of talks about “Workstations”, instead of “Personal Computer”. Fortunately PC won, and we have games, internet, Twitter, Instagram, and other totally non-work things now. Maybe we wouldn’t have any of this if we’d use Workstations, who knows.
So, if not Smart Contract, what would be a good name for a code deployed to a blockchain which is not necessary associated with legal aspects?
Blockend follows idea of Frontend, Backend. Ledgerware is from Hardware, Firmware, etc. And Chaincode is used by IBM Hyperledger already.
Basically there are few common prefixes and suffixes, which can be mixed. “Block-”, “Chain-”, “Ledger-” and “-end”, “-ware”, “-code”.
It seems that people liked Chaincode, though I think it has some problems with using it in a common software engineering context. I like Ledgerware, but maybe it doesn’t sound great too.
What could be other options?
Some time ago I deployed a token contract called BitEther Coin (BEC). The idea is simple — an ETC miner participating in this experiment is getting an additional BitEther token reward to Ether reward received from a block. The Miner gets both Ether (5 ETC per block) and BitEther (2 BEC per block).
This is not a modification of the protocol, nor is it a hard fork or soft fork. It is just a standard feature provided by the existing technology and capability of the ETC system.
By doing this I am trying to show that Ethereum Classic is not the same chain as others: it has more powerful technology which allows you to build your own blockchain layer on top of it. Security of the network can be supported by any participant or by any business building on top of the chain.
BitEther Supply Model
The BitEther Token follows the Monetary Supply of Bitcoin. My initial goal was to make it issue 50 tokens every 10 minutes, with a halving every 4 years.
In practice, BitEther «big block» time is less that 10 minutes, because an additional goal was to reach 99% of total token production at about same time as Bitcoin will. As a result, BitEther issues 50 BEC coins every 6–7 minutes, and halves every 3 years.
By microservice architecture here I mean an app split in independent parts, connected via MQ, database, internal RPC or independent APIs. Usually deployed as containerized microapps onto a horizontally scaled cluster.
Main problems with ORM
Different technology stack
Most likely you have a mixed tech stack, using different tech/framework/language for different services. Some parts are JVM apps, but others are easier to write using Golang or Python. In some cases you use an external 3rd party app, customized for your needs.
Lifecycle and backward compatibility
You probably don’t want to restart whole cluster, every single service, just to upgrade some part of the db layer. So you have to deal with different versions of Data Models, that should live together in same shared environment (remember «caching»)
Subset of data
Another important moment that each microservice operates own subset of data, and does different types of operations against the data. It’s even common to split app into microservices that do only following:
- put data into db from a 3rd party storage
- process/transform stored data
- display data for end user
Please note that this post was written long before Hard Fork happened, it wasn’t clear how it will be implemented, there were no final decision at the moment of the post
I’ve never invested in The Dao, and even was against this idea.
Doubtful about #TheDAO. Too big too soon. And if anything will go wrong, it could hurt whole Ethereum ecosystem :( hope it'll go well
— Igor Artamonov (@iartamonov) May 16, 2016
I worried because people just gave money without understanding in what they’re investing. Too many people decided to risk their money just because they thought that it’s cool, without any due diligence or anything.
I’ve been using Google Cloud since the yearly days, I think it was year 2009 when I’ve deployed my first website to the App Engine. Since then I was doing consulting, made many projects, experiments, and so on. For past few months I’ve been working on TipTop.io, it’s a SaaS solution for analytics and monitoring for applications hosted on Google Cloud Platform.
The project in the early stage currently, and it supports only Google App Engine at this moment. But support for Cloud Containers/GKE is coming soon (and probably plain Kubernetes in near future).
A quick note about office desks, seats, people and team spirit.
I’ve spend almost 15 years on software development, saw different companies, different people, different teams and different offices. Maybe hundred of them. Where I used to work, or my friends did. Some offices were small, some large. Cubicles, rooms and open spaces. Noisy and quiet. Cool startups and boring enterprise. Sometimes different offices that belongs to same organization.
At some point I’ve noticed a small difference, a difference in team members as I think is correlates with difference in how theirs work desks are placed. Remember when the same people have moved from one office to another, they started to conduct themselves differently.