7 ms·

Kadena seems like a solid team, kudos for their work. Smart contracts require you to work in a completely new language and toolset. You don't need smart contr

by jaekwon 10y ago

Kadena seems like a solid team, kudos for their work. Smart contracts require you to work in a completely new language and toolset. You don't need smart contracts to create a blockchain application, if you use the right libraries (e.g. go-merkle) and write your application to be deterministic. See Basecoin in the page below: http://tendermint.com/ecosystem http://tendermint.com/ecosystem If you want the benefits of Tendermint BFT consensus but w/ Ethereum's virtual machine, take a look at Ethermint. http://github.com/tendermint/ethermint http://github.com/tendermint/ethermint Disclaimer: I'm a founder at Tendermint, the OG BFT blockchain engine. ;)

buckie 10y ago
Smart contracts definitely have a tradeoff between new toolset/languages vs infrastructure level features. With smart contracts, anyone can write code for the chain vs the "write your application to be deterministic" approach where new code needs to be at a minimum vetted by some central org/group, though they're usually written by the vendor/provider/etc. Each has its strengths/use-cases. For inter-org I prefer the smart contract approach vs the intra-org can see the benefit of using regular code -- it's not like you're worried about malicious code in the intra-org case. I do think that smart contracts increase the utility overall (sorta like having SQL for a DB > not) and improve its reliability (accidentally non-deterministic code can be a bit worrying). As for Tendermint BFT, it's one of the few that somehow I never got to dig into at JPM. Do you know if Tendermint BFT's performance & performance-vs-scale numbers are published? These are notoriously hard to come by and I'm always curious for more data-points on the matter.
murbard2 10y ago
If you want a deterministic smart contract language, you're better off avoiding the EVM, or worse, Solidity. Tezos (plug, plug, I'm the lead on the project) has a VM with a full formal specification, and even a rudimentary embedding in Coq. It's statically typed and purely functional. https://tezos.com/language.txt https://tezos.com/language.txt
- jaekwon 10y ago
  We should plug Tendermint into Tezos as well.
  - murbard2 10y ago
    My thinking for v2 is to use Honey Badger BFT, with multi party computation for bonding / unbonding Overall I agree with Tendermint (and contra Casper or DFinity) that it's better to just drop availability and to have a less subjective security model. It sucks to get stuck if the validator set becomes compromised, but it's not the end of the world.
    - jaekwon 10y ago
      Whats the benefit of HB over Tendermint? There's a good reason we don't use threshold signatures... to guarantee accountability. We could add threshold signatures on top of Tendermint, but for most use cases this isn't very helpful (yet). In any case, building on TMSP will make Texas future proof to any consensus engine that favors safety. Let's discuss.
      - murbard2 10y ago
        Yes, getting accountability needs to be addressed, we're looking at several ways. Makes no sense to build on TMSP, governance that introspects over the consensus mechanism is a key feature. We aspire to be a utility, not a vassal.
pjc50 10y ago
Does anyone have a good solution for bugfixing and updating defective smart contracts yet, other than "fork the entire blockchain" Ethereum DAO passim? If they are to be immutable then you're going to have to code to NASA standards.
- Hermel 10y ago
  You can implement a function that migrates all of the contract's assets and data to the new version. Obviously, you need to be careful about who can call this function, maybe requiring the agreement of all (or at least a majority) of stakeholders. Also, there is a risk of hitting the gas limit, preventing you from executing a "heavy" migration.
- buckie 10y ago
  Pact[1], the language we've built, has the idea of an `admin keyset` that enables admins with the right number of signatures from the right number of keys to migrate contracts. Our approach is rather different from the EVM's as smart contracts interact with/guard a table in a DB (think stored procedures accessing a table) and the system has modules. This way, if a bug is found, the admin can update the smart contract module guarding the DB table directly vs having to track down the on-chain contracts for migration (if it's even possible). From a normal user's pov, they don't see a difference (unless the admin decides to change the namespace or something). It's a subtle but important difference. When someone using Pact sends the transaction `(payments.transfer "me" "you" <amt>)` the transaction (after doing a bunch of auth with ppk-sigs) looks up the `payments.transfer` command from the on-chain smart contract and executes it with the provided args. As such, the admin can update buggy contracts without issue (and roll-back, fix tables that have bad data). [1]: http://kadena.io/pact/ http://kadena.io/pact/

by jaekwon 10y ago

buckie 10y ago

Smart contracts definitely have a tradeoff between new toolset/languages vs infrastructure level features. With smart contracts, anyone can write code for the chain vs the "write your application to be deterministic" approach where new code needs to be at a minimum vetted by some central org/group, though they're usually written by the vendor/provider/etc. Each has its strengths/use-cases. For inter-org I prefer the smart contract approach vs the intra-org can see the benefit of using regular code -- it's not like you're worried about malicious code in the intra-org case. I do think that smart contracts increase the utility overall (sorta like having SQL for a DB > not) and improve its reliability (accidentally non-deterministic code can be a bit worrying). As for Tendermint BFT, it's one of the few that somehow I never got to dig into at JPM. Do you know if Tendermint BFT's performance & performance-vs-scale numbers are published? These are notoriously hard to come by and I'm always curious for more data-points on the matter.

murbard2 10y ago

If you want a deterministic smart contract language, you're better off avoiding the EVM, or worse, Solidity. Tezos (plug, plug, I'm the lead on the project) has a VM with a full formal specification, and even a rudimentary embedding in Coq. It's statically typed and purely functional. https://tezos.com/language.txt https://tezos.com/language.txt

jaekwon 10y ago
We should plug Tendermint into Tezos as well.
- murbard2 10y ago
  My thinking for v2 is to use Honey Badger BFT, with multi party computation for bonding / unbonding Overall I agree with Tendermint (and contra Casper or DFinity) that it's better to just drop availability and to have a less subjective security model. It sucks to get stuck if the validator set becomes compromised, but it's not the end of the world.
  - jaekwon 10y ago
    Whats the benefit of HB over Tendermint? There's a good reason we don't use threshold signatures... to guarantee accountability. We could add threshold signatures on top of Tendermint, but for most use cases this isn't very helpful (yet). In any case, building on TMSP will make Texas future proof to any consensus engine that favors safety. Let's discuss.
    - murbard2 10y ago
      Yes, getting accountability needs to be addressed, we're looking at several ways. Makes no sense to build on TMSP, governance that introspects over the consensus mechanism is a key feature. We aspire to be a utility, not a vassal.

pjc50 10y ago

Does anyone have a good solution for bugfixing and updating defective smart contracts yet, other than "fork the entire blockchain" Ethereum DAO passim? If they are to be immutable then you're going to have to code to NASA standards.

Hermel 10y ago
You can implement a function that migrates all of the contract's assets and data to the new version. Obviously, you need to be careful about who can call this function, maybe requiring the agreement of all (or at least a majority) of stakeholders. Also, there is a risk of hitting the gas limit, preventing you from executing a "heavy" migration.
buckie 10y ago
Pact[1], the language we've built, has the idea of an `admin keyset` that enables admins with the right number of signatures from the right number of keys to migrate contracts. Our approach is rather different from the EVM's as smart contracts interact with/guard a table in a DB (think stored procedures accessing a table) and the system has modules. This way, if a bug is found, the admin can update the smart contract module guarding the DB table directly vs having to track down the on-chain contracts for migration (if it's even possible). From a normal user's pov, they don't see a difference (unless the admin decides to change the namespace or something). It's a subtle but important difference. When someone using Pact sends the transaction `(payments.transfer "me" "you" <amt>)` the transaction (after doing a bunch of auth with ppk-sigs) looks up the `payments.transfer` command from the on-chain smart contract and executes it with the provided args. As such, the admin can update buggy contracts without issue (and roll-back, fix tables that have bad data). [1]: http://kadena.io/pact/ http://kadena.io/pact/