Manufacturing Consensus

[CIYAM]

Whilst there have been some very interesting developments over the last couple of years in regards to consensus ledgers and "Turing complete" smart contracts there has actually been little to zero change in the way that people are creating software.

The CIYAM project has always been focused primarily on changing the way that software is created and this process has been described as Software Manfacturing for very good reason. In CIYAM applications there is simply *no manual source code* created at all - all the source code is generated (and if you think you couldn't create something that works well and looks okay when it is 100% generated then I suggest you take a look at http://ciyam.org/open).

This same approach is being applied for the creation of CIYAM blockchain applications (and steady progress is being made which can be followed here: https://bitcointalk.org/index.php?topic=598860.0).

Having created Automated Transactions (http://ciyam.org/at) and helped with it being implemented in two different blockchains (with two different code bases) I have come to the conclusion that it (and similar technologies such as Ethereum) are really not going to be the "way forward" (they have been an interesting experimental step though).

Running a VM (be it a Java-like one like Ethereum or a virtual CPU like AT) is basically slow - and when it is being "instrumented" (in order to limit its steps according to an account balance or amount of "fuel") it is actually even slower.

But do we need to actually do this in order to implement generalised smart contracts?

In my opinion we do not. A much more efficient approach is going to be to instead instrument "operations" that are described at a much higher level (and implemented by a generalised application server).

Using SQL is a very high-level method of working with an RDBMS but unfortunately does not enable any tight controls in terms of efficiency (i.e. you can easily create a very inefficient query that would tie up both CPU and I/O resources), however, if you have a very high level approach that does enable tight controls you can achieve such efficiency.

So such an approach won't be exactly like SQL but will be somewhat similar (with tight controls in the application server to prevent inefficient operations from being processed) and this is exactly what the CIYAM application server was designed to do (even before I'd heard of Bitcoin).

Therefore in my opinion the future of consensus applications is not going to be low-level VMs but instead a very high-level approach.

Feel free to discuss and disagree but any trolling, insulting or pointless posts for the sake of ad-sig posting will be deleted.

[1714186316]

1714186316

[1714186316]

1714186316

[1714186316]

1714186316

[1714186316]

1714186316

[1714186316]

1714186316

[CIYAM]

Hmm... did I intimidate any potential posters?

[dannote]

I get what you're saying about Ethereum-style contracts (Java-like) and AT-style contracts (running on a virtual CPU) being too slow on current computer systems (this is why BitShares went for an extensible set of high-level operations for given problem domains like distributed exchange transactions, voting, etc instead of a low-level scripting language).

If I understood your post correctly (and I'm far from sure of it at this point), you want to support some kind of SQL-like API to the distributed data stored in the blockchain and "commits" would involve pushing a transaction to the blockchain that updates the database. Do you have examples yet of usages of your API that would clarify how this would work for common smart contract applications.

[alwinlinzee]

Hmm... did I intimidate any potential posters?

May be, due to the technical nature of what you are talking about but i do not have any doubt that you will receive good feed back if you post this in the technical section of this forum.

[CIYAM]

Do you have examples yet of usages of your API that would clarify how this would work for common smart contract applications.

I actually have a sample application for messaging which I'll probably set up for public "playing around" under ciyam.org in the coming weeks.

But what I can show here is a simplified version of the "transaction log" to clarify how it works at that level:

Code:

[1]Key=201510231038500171872079,Type=Message
Owner=12345,To=54321,When=2015-10-23 10:38:50,Subject=Test Message
Content=DfYqrnq07o8plln+vEQSNcXCvWHEIp/CWs7rXOzhNFWftNDP8CGvpFMKXkiD9oMiKulQ1ywDhcY8Fwe

This would be the tx broadcast to create a private message (it would be encrypted using AES from the hash of the creator's password that is salted and put through X rounds of SHA256).

Note that at this point the message is in a "draft" state (and could be updated by its creator if so desired). So the blockchain is acting as a shared storage for draft messages.

Code:

[2]Key=201510231038500171872079_54321,Type=Message,Source=201510231038500171872079
Owner=54321,Content=AjHrLXrGEh/I81DnFH2YyAT6yn1U3RKJop+Kig5CDOS4,pt=8kAGB39T66zhTXASJ0foMOrAWQ35bR

This would be the tx broadcast to send the private message to 54321 (there would be one of these per recipient in the case of multiple recipients). The content would match that of the first tx but would now be encrypted using a key that is derived from an ECDH shared secret (so that that recipient can decrypt it).

The rest of the record's data is cloned from the initial one (and the initial record would now been changed to a "sent" status so it can no longer be updated). It should also be noted that the second record's content cannot be edited (by any party) only some non-essential state (such as a "read" flag) would be permitted to be changed.

[lexxus]

I'm not sure that I got your idea fully but I think that you are on the right track in terms of separating "smart contracts" into several more or less independent components. I tend to believe that an architecture of loosely coupled components in which each components is responsible for a small and preciese operation works better rather than one-big-blockchain-to-rule-them-all (like Ethereum).

The most straigtforward is to separate (as I see it)

- messaging (ability to exchange messages among contracts)
- storage (e.g. sql/no-sql for contracts = simple application server that only supports CRUD operations)
- execution (buisness logic of contracts = application server, Codius can serves as an example)

I'm currently working on a toy project (which derives heavily from BitMessage ideas) that concerns messaging.

[CIYAM]

I'm currently working on a toy project (which derives heavily from BitMessage ideas) that concerns messaging.

A blockchain version of the CIYAM Message package has been created (and is just getting some polishing touches).

Someone creating an application that uses it doesn't need to do anything more than the following steps (using the Meta application which is the IDE and assuming a genesis block has already been created for which some further work will be done to make that just as easy as the following):

1) Create a Model and give it a name (let's assume "Sample").

2) Install the blockchain User package (this is necessary for applications to have users).

3) Install the blockchain Message package (which supports encrypted messaging).

4) Create an Application and give it a name (to make things simplest use the same name as the Model so "Sample" again) and supply the blockchain identity (just a copy and paste from the genesis block creation).

5) Click "Generate".

Done.

I think this is rather way ahead of anything like Ethereum (despite having no funding).