3 ms·

I agree with you that not everything has to be done a certain way. Programs don't have to be written in C or functional programming for it to work well. But the

I agree with you that not everything has to be done a certain way. Programs don't have to be written in C or functional programming for it to work well. But there are places where those excel in terms of performance and/or reducing complexity. I am also not arguing that incompatible APIs will disappear with blockchain usage. But things like an EVM can be used as a template to build underlying blockchains to provide a common datastore and execution layer for multiple systems to work together. It is harder to achieve with traditional SQL databases, which shouldn't be publicly accessible. Also an advantage I thought of is it would be harder in this case for corruption to take place in the PCR testing regime since all transactions are immutable, and transparency ensures that the public would be able to check against those if they so wish. A closed system would allow the government or participating platforms to manipulate data records for their benefit, with less chance of scrutiny. I agree with your points about the vulnerability of smart contracts and private keys. These are challenges that I hope will continue to be addressed as we try to figure out how to make blockchains accessible for mass usage. I think that smart contracts auditing is still far from mature, but the immutable nature of contracts would allow audited contracts to remain secure, as opposed to some code running on some company's server. In the end as with everything in life, there are trade offs. It's about picking the right tool for the right job, and to continue experimenting with potential improvements that new technologies can bring and to reduce their externalities.

hiq 5y ago
> But things like an EVM can be used as a template to build underlying blockchains to provide a common datastore and execution layer for multiple systems to work together. Substitute EVM for JVM and you end up with a similar statement that looks just as correct, but it's still not clear what the EVM brings that the JVM doesn't. > it would be harder in this case for corruption to take place in the PCR testing regime since all transactions are immutable In your system, the blockchain would replace the database, not everything around it. That's also something I keep seeing in these discussions: blockchain provides some guarantees, so you assume the system you'll build on top of it will inherit from these guarantees, without questioning the composability further. But the interfaces of the blockchain component of these systems you're trying to conceive are precisely where the guarantees break down. To take your example, you'd basically replace a database (and just a database) with a smart contract, which would ensure immutability and transparency. But: 1. you don't need a blockchain to get these guarantees (e.g. https://en.wikipedia.org/wiki/Certificate_Transparency)[0] https://en.wikipedia.org/wiki/Certificate_Transparency)[0] 2. using blockchains still imply that you're trusting the people holding the keys and interacting with the smart contract, so you haven't changed your trust model (the interface problem I mentioned above). > the immutable nature of contracts would allow audited contracts to remain secure The immutable nature of contracts is also what makes them unfit for evolving systems that have to be regularly updated to address new requirements. [0]: to be clear, I'm talking about permissionless blockchains such as Ethereum
- freemanon 5y ago
  First of all, let me say that I understand where you're coming from. I too try not to use the latest fad just because of it. I use systemd instead of k8 when it's enough. I use plain JS instead of react when it's enough. I run cronjobs that updates jsons served by nginx instead of building graphql APIs. But there's a good reason things like k8 and react become overused for everything these days, because they provide a standard that works for a relatively large spectrum of cases. The argument of "you don't need X to do Y" is not wrong, but it doesn't make X absolutely useless. Your points are not really invalid imo, but i think you're missing the point of the continuum between centralised and decentralised systems
  - hiq 5y ago
    > i think you're missing the point of the continuum between centralised and decentralised systems I'm mostly missing the point in this continuum where I can start listing pros instead of just cons. There are fundamental reasons why we haven't reached this point and may never reach it, as I (and many others) highlighted before, and these haven't changed for the past 5 years.

hiq 5y ago

> But things like an EVM can be used as a template to build underlying blockchains to provide a common datastore and execution layer for multiple systems to work together. Substitute EVM for JVM and you end up with a similar statement that looks just as correct, but it's still not clear what the EVM brings that the JVM doesn't. > it would be harder in this case for corruption to take place in the PCR testing regime since all transactions are immutable In your system, the blockchain would replace the database, not everything around it. That's also something I keep seeing in these discussions: blockchain provides some guarantees, so you assume the system you'll build on top of it will inherit from these guarantees, without questioning the composability further. But the interfaces of the blockchain component of these systems you're trying to conceive are precisely where the guarantees break down. To take your example, you'd basically replace a database (and just a database) with a smart contract, which would ensure immutability and transparency. But: 1. you don't need a blockchain to get these guarantees (e.g. https://en.wikipedia.org/wiki/Certificate_Transparency)[0] https://en.wikipedia.org/wiki/Certificate_Transparency)[0] 2. using blockchains still imply that you're trusting the people holding the keys and interacting with the smart contract, so you haven't changed your trust model (the interface problem I mentioned above). > the immutable nature of contracts would allow audited contracts to remain secure The immutable nature of contracts is also what makes them unfit for evolving systems that have to be regularly updated to address new requirements. [0]: to be clear, I'm talking about permissionless blockchains such as Ethereum

freemanon 5y ago
First of all, let me say that I understand where you're coming from. I too try not to use the latest fad just because of it. I use systemd instead of k8 when it's enough. I use plain JS instead of react when it's enough. I run cronjobs that updates jsons served by nginx instead of building graphql APIs. But there's a good reason things like k8 and react become overused for everything these days, because they provide a standard that works for a relatively large spectrum of cases. The argument of "you don't need X to do Y" is not wrong, but it doesn't make X absolutely useless. Your points are not really invalid imo, but i think you're missing the point of the continuum between centralised and decentralised systems
- hiq 5y ago
  > i think you're missing the point of the continuum between centralised and decentralised systems I'm mostly missing the point in this continuum where I can start listing pros instead of just cons. There are fundamental reasons why we haven't reached this point and may never reach it, as I (and many others) highlighted before, and these haven't changed for the past 5 years.