New to Busy?

Comparing Steem Engine to dstors and dlive

36 comments

inertia
71
2 months agoSteemit8 min read

Remember when @whatsup mentioned dstors and dlive in the same post? It didn't go well. The project self destructed after a few pointed questions. Nice going, @whatsup (kidding). So I have an idea ... let's try the same process on another project: Steem Engine

Will it self destruct at the mere mention of some pointed questions too? Spoiler: I highly doubt it.


The Good:

  • They're not asking for delegation - Not that there's anything wrong with asking for delegation. But that's not on the table so it's a non-issue.
  • It's not a fancy bid-bot-with-extra-steps. - Related to delegation, there's also nothing inherently wrong with this either, even if it's your only value proposition. Again, non-issue.
  • It's on the blockchain. - Create/issue/transfer tokens basically on-chain ... sort of. This is good, though because it's showing the utility of Steem to provide solutions.
  • It has UI. - You don't need to be technical to create a token. Nice.
  • It (might) indirectly strengthen Steem Monsters - If you've invested in Steem Monster cards, research being done on Steem Engine will in theory trickle into Steem Monsters, where applicable.
  • The code is on github - It's right there, or at least a version of it. Still, it's a big plus. [1]
  • Responsive and nice developers. - I grilled them and they didn't cave. They didn't hurl insults. Their answers made sense. In fact, they were receptive to my suggestion about batched actions. [2]

The Bad:

  • No whitepaper. Is that a deal-breaker? No. In fact, they do have a nice FAQ, so maybe that's a non-issue. But it'd be nice to see what their revenue model might be.
  • It claims to be a sidechain yet the industry hasn't really defined exactly what that is. But the industry isn't old enough nor established enough to come together to agree on terms. Does that mean sidechains are bad? No. No more than it means Blockchains are bad because the industry hasn't fully defined them either. We may think we know what a sidechain is. It just means that Steem Engine is in uncharted territory.
  • It claims to execute smart contracts, but requires a trusted node, thus, not a smart contract. Again, "industry standards" have to be invoked but I think using the term "smart contract" is actually the least accurate claim. A real smart contract executes with public code and confirms cryptographically. These "actions" execute on a trusted node somewhere, and that's all we know for the moment. Steem Engine might eventually have fully realized smart contracts, if other pieces come together.
  • No validation nodes have been defined let alone incentivized. Nodes are defined in a general sense, but not specifically for Steem Engine contracts. This means only Steem Engine is the authority for the tokens they've issued. Is this actually bad? I could be convinced it's not bad, but it leads to the next issue ...
  • Not fully decentralized. I mentioned in The Good that it's "on the blockchain." But if that's true, then how is it also centralized? Because validation nodes and peer-to-peer consensus have not been defined, yet.

I may have categorize these as "bad" but I don't think any single item here is a deal-breaker.


The Ugly

I just included "The Ugly" because of that one cowboy trilogy. I don't really think there's anything particularly ugly here. Certainly no more ugly than anything else in software development.

The devs involved in Steem Engine are responsive and knowledgable; so far, my interaction with them has been the complete opposite of ugly.


Unfair Comparison

How does this compare to dlive? Not at all, really. Dlive wasn't ever on the chain in any meaningful sense.

What about dstors? In theory, they were going in the direction of on-chain ... or something. It's not really clear, dstors was all vaporware. It's dead and was never actually on the chain either.

Look, the title is clickbait, ok? 😏


The Pointed Questions

I promised pointed questions. I just wanted to make sure we were all on the same page with terminology, first. So here are my questions followed by answers given to me by the Steem Engine team:

Q: What is the revenue model for Steem Engine?

A: Currently the revenue model is selling ENG tokens which are needed to create new tokens on the platform and will be needed for other things on the platform in the future as well. ... Currently ENG spent to create new tokens are burned.

Q: Is this model enough to support future development?

A: That depends on many factors outside of our control, however there are a number of potential options to support future development if funds from the project itself are not sufficient. Ultimately, as long as this project is providing value to the Steem platform it is likely it will continue to be developed.

Q: In what sense is Steem Engine decentralized?

A: The software is open source and available for anyone to run and is not reliant on us or any other entity.

Q: How do third-parties validate?

A: Until a proper consenus layer is added, people can query the nodes in two different ways and compare the results of these queries:

  • pull each block of the sidechain [3] of each nodes and compare their hashes
  • perform random queries against the database of each nodes and compare the results

Q: How will [third-party validation] evolve moving into the future?

A: Our plan is to add new built in features, such as the internal market to trade the tokens against STEEM, to open it up to running third-party smart contracts, and to build out the p2p consensus mechanism.

Q: Are there code repositories related to Steem Engine that have not been published?

A: All of the software is currently published and open source.

Q: To what extent will Steem Engine support third parties who want to run their own validation nodes so they can do things like execute arbitrary contracts that deal in Steem Engine tokens, but without directly involving Steem Engine's infrastructure?

A: The Steem Smart Contracts software that runs Steem Engine allows for users to publish arbitrary smart contract code, similar to platforms like Ethereum and EOS. Until that feature has been fully tested and a fee structure put in place the software being run on the main network sidechain we are calling Steem Engine (id: ssc-mainnet1) only recognizes smart contracts published by the @steemsc account which we control.

Q: In other words, to what extent must third parties rely on Steem Engine to execute contracts, if at all?

A: If certain projects would like to publish their own smart contract on the Steem Engine platform, we will work with them to develop and test the smart contract and publish it for them from the @steemsc account.

Q: With the known caveat that in the early implementation, being that Steem Engine has declined to execute arbitrary contracts, if a third party wanted to side-step this limitation and just move forward using the same basic tooling, would they just be considered a competitor sidechain to Steem Engine and would that hinder cooperation?

A: Anyone is free to run their own sidechain with a different ID and modify they code as they see fit, just like anyone can run their own Steem chain; however, in that case their smart contracts will only be able to interact with tokens and other smart contracts on their sidechain and not with the tokens and contracts on the main Steem Engine chain.

Q: Why is Steem Engine currently using native JSON floating-point in contract payloads?

A: In the end you will need to convert the string to a number so @harpagon chose to go with numbers directly.

Q: If you're using JSON specific types, do you intend to publish which JSON Schema you're adhering to?

A: This is standard JSON that’s available with native javascript.

Q: Will merely holding ENG tokens ever provide benefit to the holder (I'm specifically wondering if ENG would ever be a staking token or if it's just a "GAS-like" mechanism (i.e., ENG must always be consumed to create/issue/transfer other tokens))?

A: That is TBD at this point.


Conclusion

In my opinion, this is not a smart contract solution. Instead, it's better described as what Vitalik referred to as a general purpose oracle:

The oracles would run the code, and if the code execution leads to a withdrawal from the contract to some particular address then the oracles circulate a transaction sending the funds and sign it.

What it boils down to is, what are your expectations? Do you want to issue a token that is tracked on Steem? This is great. Can the technology be used for other things? It already is and seems pretty stable.

Is it cryptographically verifiable and fully decentralized? Not yet. But I guess you gotta start somewhere.



Footnotes:

Comments

Sort byBest