Poll: Soft Consensus?
In our recent update the Steemit Team disclosed that we think a lot of potential lies in Soft Consensus. This isn’t to say that Hard Consensus isn’t important, critical even, only that the obsession with putting everything in Hard Consensus is creating a gap in the market that presents a unique opportunity for Steem.
TL;DR
What’s a better marketing term for “Soft Consensus?”
- Soft Contracts
- Smart Consensus
- Make a different suggestion!
Blockchain Blindspot
Because people fail to distinguish between Hard and Soft Consensus, they don’t even see the potential lurking right in front of them. Information stored in Soft Consensus IS stored "in consensus." The distinction is that this information does not motivate the blockchain protocol to perform unnecessary computations.
What Web Developers Really Want
I believe that the failure to distinguish between these concepts has created a huge blindspot in the market. In my capacity as Head of Communications and Advocacy for Steemit I’ve spoken to hundreds of entrepreneurs and developers about the applications they are trying to build.
I can say with absolute certainty that the vast majority of features they are trying to develop using blockchain do not require that their code be executed by the network. That’s not to say that there are NO features that require decentralized code execution. Not at all.
Smart Contracts Bad?
I think smart contracts are a brilliant innovation. I’m just saying that based exclusively on my experience with entrepreneurs and developers who are building blockchain applications, the vast majority of features they are trying to implement in their app objectively do not warrant smart contracts.
These people are either misinformed or simply doing it that way to attempt to capitalize on “blockchain hype." Unfortunately they don't realize that the cost and friction of implementing features that way will knee-cap their application, and doom them to failure. Just look at how many projects which ICOed are now dead.
Soft Consensus Limitations
Like everything, Soft Consensus has its limitations. Blockchain as a technology offers essentially 3 value propositions: transparency, immutability, and decentralized computing. If a feature only requires transparency and immutability, then the conclusion is simple: you should be using Soft Consensus. In such cases, it’s highly unlikely that you’re going to find a better protocol for powering those features than Steem due to its low cost, high speed, and vibrant community.
Unique Value Proposition
When you find a powerful feature that your product offers that no one else does, we call that a “unique value proposition.” Unique Value Propositions are the foundation of any marketing strategy. So the question is, “How do we tell people about this Unique Value Proposition in way that gets them interested in our product?"
We need our own version of “Smart Contracts.” Every serious person in the blockchain world understands that there is nothing inherently “smart” about smart contracts, nor is there anything especially “contract-y.” But it uses terms we are all familiar with and it hints at features in a way that entices you to fall down the rabbit hole. I think something like that for Soft Consensus would deliver a ton of value to the Steem ecosystem.
Two terms I’ve been playing around with are:
- Smart Consensus
- Soft Contracts
Smart Consensus
While “consensus” is a somewhat technical term, it does have a standard definition, so even ordinary people are familiar with it. Certainly blockchain people are and they are a key demographic for Steem. Calling it “Smart” accomplishes a few things. First, it creates a dichotomy in the listener’s mind by implying that there is another type of consensus that isn’t smart. Second, it implies some kind of parallel with Smart Contracts. I believe our strongest argument for Soft Consensus is that it is a "smarter" way to store much of an application’s code on a blockchain.
Priority #1
Whenever you’re marketing something, your objective is not to rationally convince people that your solution is technically superior. Nor is it your objective to explain what your product does. You have one simple objective: get them interested. Get them asking questions and frame the conversation so that you can go on a journey together during which you will discover how the product will reduce pain and increase pleasure. We’re looking for terms that help us get people interested and enable us to begin that journey with them.
Soft Contracts
This term again plays on the concept of Smart Contracts which is, without a doubt, the most successful marketing maneuver in the history of the blockchain space. Why not piggyback off of that success? Familiar terms make people more comfortable with novel concepts. In this context I think “Soft” is more descriptive than “Soft Consensus” because it is qualifying the word “contracts.” It implies that these are “contracts” which will not be enforced in a “hard way,” which is pretty accurate!
The Poll
But what do you think? Smart Consensus? Soft Contracts? Have other ideas? I’d love to hear them in the comment section below!
Good question!
Personally, I think the terms "soft" and "smart" don't really describe anything. In fact, the term "soft" works against you from my perspective. Synonyms include mushy, weak, et al. Consensus and contracts are both supposed to be rigid and strong, even if flexibility is built into them, because they represent some kind of finished state that has been agreed upon so that it can be referenced later in case of disagreement or an error. They're associated with stability and guidance. Saying something is "soft" tells me that it's not really consensus or that it's contractual. It conveys "informal" to me. It screams weak.
The other word "smart", also doesn't tell me anything about the function of the contract or what "it's about". It's a buzzword that doesn't have any substance behind it. I think both of these adjectives confuse more than they clarify.
I'd choose something along the lines of "dynamic" or "adaptive".
Dynamic conveys a state that exists within a framework that can change when variables within that framework change. It says fast, calculated and decisive. Adaptive conveys flexibility, reactivity and strength.
I like it! Dynamic!
Yep, "Dynamic Consensus"
Let me first start by saying that I'm a big fan of soft consensus and my preferred term for it is embedded consensus. I even think that a better approach to SMT than trying to build a lot of complicated functional into the blockchain that will be very difficult to ever test and establish quality control with a high degree of confidence (compare the scope and complexity of SMT with the past two hard forks which have been a disaster on that score), and then will continue to be very difficult to upgrade, would be to embrace Steem-Engine (or its current developers aren't agreeable to fully open sourcing and decentralizing it, clone it instead) and develop it further with a clear, well-documented, well-supported, and fully fleshed-out decentralized embedded consensus model.
That being said, I'm also very put off by the constant anti-smart contract drumbeat that seems to come from Steemit. As noted by @blocktrades elsewhere in this thread, smart contracts are a way for the blockchain to support certain forms of computation without needing to hard code every single operation into the core consensus layer, require forks for each and every change and update, and possibly destabilize the core layer interrupting or damaging service for every single user.
Given the approach of RC it would be quite possible to support smart contracts for those application which really benefit while limiting (by cost) the ability of unconstrained smart contracts to weigh down the whole system and destroy decentralization via bloat. For a great many functions which do not need to be nor benefit from being executed and validated within the core layer, relative RC cost would encourage developers to use a soft-consensus approach instead. That may be a lot, but without an enormous amount of convincing (which we are poorly positioned to do as a small minority blockchain and project in a larger marketplace) and in some cases serious technical compromises, it isn't everything.
So yes, I'm all in favor of soft consensus aka embedded consensus, and I absolutely agree it can be made fully decentralized and be a very powerful side-chain-like approach, but I don't think we need to engage in a religious war against native smart contracts which are extremely popular with blockchain application developers and unquestionably useful (including as a bridge for making embedded consensus more powerful and useful). Such a war only serves to marginalize us and make Steem less useful to certain application developers (possibly a very large and wide subset). We should instead embrace both, which was always the original vision of Steem to begin with.
How and why did we get off this track?
I can't agree more on this
I couldn't agree more with this, "We should instead embrace both, which was always the original vision of Steem to begin with."
If the message from Steemit seems contrary to this, then we need to change the way we're communicating about it. Figuring out how to talk about Steem's hybrid approach to consensus is my real goal here. Maybe I'm asking the wrong question and the right question is, "How do we talk about Steem's unique approach which features both hard and soft/embedded consensus." But in a way that ordinary people can understand.
"Steem uses a novel hybrid approach to decentralized computing which features both hard and embedded consensus. This provides the security of smart contracts with the flexibility of traditional programming." Thoughts?
Somebody made a post explaining how Steem is an ASIC to Ethereum's FPGA. I like the analogy and hopefully developers are aware of this kind of hardware terminology as well. Steem can easily become the authentication layer to the decentralized internet of content or other similar marketing terms.
My view is that actual smart contracts are very useful and can play a role, often for bridge purposes in interacting with native functions of the chain such as access control, token movement, etc.
Almost every single blockchain including Bitcoin (almost the poster child for simplicity and stability over functionality) has at least some limited form of smart contracts. They're very useful for bridge purposes such as atomic swaps, token exchanges, adapters to lightning-network-like solutions, for security features such as time locks, two/multi-factor authentication without custody, etc. This does not mean that you build an entire application into the blockchain and expect consensus nodes to verify it for you for free, but there are portions of many applications that are useful for the core blockchain to support natively without the hard coding, risking the stability of the core chain, and hard forking the way we have been doing it.
I think we should stop hating on real smart contracts and should embrace them (with appropriate controls on resource use and bloat via RCs) in addition to soft consensus, not keep trying to pitch soft consensus as an alternative. For many applications it is, but for many others (at least not without great difficulty and enormous unforced marketing challenges) it is not.
We are marginalizing ourselves unnecessarily by trying to convince developers they don't need something they think they need. The better approach is to give them both and let them choose the tool they want to use.
"Soft consensus" is verifiable but there might be better terms for coming to consensus via Steem messaging(custom, custom json, custom binary) and collaborative nodes. Distributed consensus, smarter contracts... Some of the code I have written even allows these nodes to elect themselves as signatories to a multi-signature account giving them all the power and legality of ethereum smart contracts as DAOs.
Anything Ethereum can do we can do "sharded" but marketing has never been my strong suit.
First of all, I'm really happy to see this post, this is how steem should be marketed.
I don't like smart consensus, it just sounds really bad.
I prefer soft contracts, where soft indicates unconsciously that they are easier to code and more scalable. However, this might pit us unnecessarily against Ethereum. Soft Contracts vs Smart Contracts. They clearly win with network effect.
I do like "Soft Consensus" as it is. Steem is a pioneer as an app specific soft consensus platform, and should be marketed that way. I think "soft consensus" can catch on and become considered as a new category for blockchains.
There are peer to peer currencies, Smart contracts platforms, and now soft consensus platforms. "soft consensus" sounds good, describes Steem correctly, and makes out of Steem the "new trend" in crypto, not just another competitor to Ethereum, like eos, tron, tezos, neo etc...
But, the names should be tested with people who hear "soft consensus" for the first time. Maybe it won't sound as good to them as it does to me. I remember though, the first time I heard it from you @andrarchy was in a video where you were interviewing someone and it instantly clicked with me.
I think Smart Consensus is preferable as it implies as you point out, this is the better version of the alternative. However consensus is a term not broadly understood or used outside crypto.
Soft contracts seems to convey weaker or “less” safe or less enforcement, which could be interpreted as your investment is at greater risk.
Smart Contracts uses two well known terms, so even if their are no contracts, people assume they understand.
A different version of this combination using terms common people understand to convey equal safety but unnecessary parts have been removed like lean or thin would be interesting alternatives.
Thin Smart Contracts or Lean Smart Contracts adds the notion of an improvement on a product which is well established and has name recognition, but suggests un-necessary elements have been removed. Which I think is the point your making.
This allows you to take advantage of all marketing which was done before you to get people to “recognize” your product as something they know.
And every time they hear “Smart contract “ they may think of your product and say to themselves yes I have heard of Smart Contracts and I know of an improved version.
This also allows people to do your advertising for you, as they seek to spread the word on your product to show others they are keeping up with the changes in the niche, they are more knowledgeable then their coworkers or competitors..,
What do you think?
I totally see where you're going with this post: use a catchy name, instead of a descriptive one, and maybe it is the right thing to do from a marketing perspective.
But at the same time, when I think of all the damage that terms like "smart contracts" have done in the long run to people's ability to reason about blockchain capabilities, I'm not sure I can get behind the idea.
At least in the case of smart contracts, a full description of what they actually are might have led to the coining of the name. After all, saying something like "our blockchain supports adding computational algorithms without requiring a consensual upgrade of the software" is a bit of a mouthful. So much easier to say our blockchain supports smart contracts, even thought that sounds like it means something else.
But if I get the meaning of what you're referring to as "soft consensus"/"soft contracts", you're just referring to custom/arbitrary data that is stored in the blockchain. So it could just be called "customized consensus data" or "custom decentralized data", which is considerably more descriptive, I think, than your terms. I'm only putting the term "custom" in there to indicate the format of the data is left up to the person introducing the data, maybe there's a better word. On the other hard, I do admit your terms are more "cool sounding", so maybe marketing buzzwords are the pragmatic way to go. It just pains me to hear them.
I agree that this should be discussed. I'm in favor of Efficient Consensus
Interesting!
I thought if this as well but does it seem like a mouth full to say?
Nah, it has nothing to do with Consensus, it has to do with decentralized execution. The consensus is still the same as any other DPOS.
Steem Contracts: All of the engine, none of the gas
What about: Lateral Consensus
"Lateral" from Latin lateralis, from latus, later- ‘side’.
Tangentially related: https://steemit.com/math/@inertia/mathematical-fantasy-vs-reality
My preferred term for this type of logic is "derived state" (or derivable). I see @smooth calls it "embedded" which I think is also a fair term, but I still prefer derivable -- because you have to derive the state first to understand what state is embedded.
"Soft Consensus" is such a poor choice for this, because it is not consensus related at all. This word should really be isolated from the idea. Consensus is only useful to determine ordering on actions, and this is done at the base layer.
In the case of a 2nd layer solution, you base on the assumption that you already have consensus on ordering. With this as a prerequisite, deriving ones desired state becomes deterministic. In essence, with deterministic state, so long as you are using the same "ruleset" to govern the creation and modification of this state, independent observers witness the same result.
The notion of "decentralization" also does not apply to the state as it is deterministic. One should rather argue about decentralization in the context of who would be able to convince all followers of a ruleset to update or change their ruleset, if some update logic was not originally programmed into the ruleset. If ruleset update logic was baked in, then how control is designed here would I suppose determine decentralization. (Also why "side-chain" is a poor term, it is simply a ruleset, not a chain).
Consider this following as an example of why this is: a "blockchain" could store actions that were attempted but fail (e.g. alice tries to send bob money she doesn't have). All observers deriving state with the same ruleset, and given a consistent ordering of actions -- when they come to this action, all agree it fails. There is no theoretical reason to avoid storing this failed action, only a technical reason (to prune useless data). A 2nd layer solution functions in this fashion by having all observers of a "ruleset" agree on what succeeds or fails, even though failed actions will be stored. Bloating / storing too many failed actions is already limited at the base layer (e.g. resource credits).
The major drawback of this type of 2nd layer data is that it is encapsulated; it cannot cause programmatic actions to occur on other (or the base) rulesets. Crossing boundaries is active rather than passive, requiring some form of 2 phase commit (for example, atomic swap).