discovan's comments

I tried to avoid being so categorical. However, this is the conclusion I have come to so far)

The thing is, auditors already use security tools as part of the audit, so do developers. Now they will have a possibility to do it much easier.

Besides, when you have the tool that integrates with other developer tools, you can embed it into the development process, which is a good security practice.

So, the answer is yes)

Wow, thanks for the great question. The thing is, the tool can also scan bytecode for some platformes, which includes Android and iOS. It's kinda spoiler, I saved this info for the next article)

Frankly speaking, I cannot say it is necessety. We were trying to find a way to utilize the technology for the hacathon so that it will bring value.

And yes, it did consume a lot of time. First we wanted to use ZoKrates to generate Rust code for Fluence. However, we found out that it does not generate Rust source code - only bytecode. So, we had to write the code ourselves, which was pretty complecated since none of us knew Rust) A mentor from Fluence team helped us a lot. Also, we contunued working on that part after the hackathon, too.

Yes, that kind of instrument (with crypto under the hood) would not be perfect or "pure". However, people use cash or banks, which are perfect neither, and benefit from it. Anyway, we should better try to build it than try to guess how it will be used.

The question is: does it make using blockchain pointless? I don't have the answer. The thing is, the only working blockchain use case - money - does not operate with real-world (non-reliable) data.

That's right! "Even though blockchain does not allow for modification of data, it cannot ensure such data is correct. The only exception is on-chain transactions, when the system does not need the real world, with all necessary information already being within the blockchain, thus allowing the system to verify data (e.g. that an address has enough funds to proceed with a transaction)."

However, I disagree that current money systems solve the problems solved by Bitcoin, but this is completely different discussion)

I agree! I don't consider audit use case here(mostly not to make the article too big, saving this example for further reasearch and publications), as well as many other "reducing trust" use cases. Do you have any example of such systems being implemented?

Thank you so much for such a detailed comment!

I agree about your first point: acknowledging only trust elimination and denying trust minimization is a simplification from my side. However, I have not seen successfull examples of "trust minimization" so far though it is always suggested in the context of blockchain. Maybe the reason is that the part on which the trust can be minimized by BC is usually not the weekest link.

I also agree that BC could prevent some percent of deed frauds. However, if you consider my argument about not decentralized example land registry BC maintenance you will agree that in many cases this may leed to a forgery, not possible in Bitcoin blockchain.

I completely disagree on a tokenization part. Unless we have a well-described and tested business model. these are more dreams and handwaving than a real use case. It is easy to say "tokenize this and that", the devil is in the detailes.

Actually, I come to a similar conclusion in the article) Just trying to be less categorical and give them a chance)

Trying to keep as hot as possible without misrepresenting the contents)

- to me they seem like a solution waiting for a problem

I feel exactly the same. However, SC are a very interesting technology. I prefer to study it now, to be ready when the humanity is OK with electronic money (cryptocurrencies) and come to electronic contracts.

This is a problem of lack of decentralization in Ethereum. This is not a problem of smart contract as a concept.

Actually, smart contract DOES override existing law - if the subject of the contract is fully on-chain. In that case you can engage all the courts and police in the state, still, they won't be able to undo your transaction. Obviously, this does not apply to the example with PS3.

Contracts (both smart and traditional) are first of all logic constructions. And thus: 1) this logic can be implemented with vulnerabilities, no matter in paper or software form; 2) this logic can be bad by design, allowing undesired behavior of contractors. These are not problem of smart contracts only, but problems of any kind of contracts. They are much older than any software. And they need to be solved (at least partially) since people need contracts for the economy to function.