301–310 of 333 posts
Earlier quoted context omitted.
Looking at the various issues that have come up with these ‘smart contracts’ (aka the ethereum DAO issues up until now), I think anyone who wants to write one should be automatically excluded from being allowed to do so.
They should maybe be forced to learn what a dependent type system is so they can regret that their smart contracts are written in a language with no safety features.
Earlier quoted context omitted.
If Code is law then hard fork is also law. Otherwise those Ethereum classic people are saying that code is law but only the DSL of Solidity. Outside updatable Ethereum engine code is not law.
> If Code is law then hard fork is also law Not at all. All crypto currency only has value because other people collectively choose to "believe" a certain chain. Usually there is global consensus of which chain is the "true" chain, but there have been many times in the past that one group has decided to follow a different fork for whatever reason. I mean, Bitcoin has Bitcoin, Bitcoin Cash and Bitcoin Gold. The value…
Earlier quoted context omitted.
Solidity is a DSL. DSLs have their purposes and this happened to be a correct purpose. It just also happens to be that Solidity is a terribly designed language.
In what way is Solidity terribly designed?
And it worked.
It is surprising that people would entrust large amounts of money to Turing complete C-like programming languages in an environment where mistakes are irreversible. Surely you would want to use a language that makes it harder to accidentally introduce common vulnerabilities? For example, considering contracts are likely to be state machines (and the error in this case is a state machine issue), maybe an explicitly st…
Earlier quoted context omitted.
so where does one draw the line between theft and just doing what the code allows? I wonder in the future crypto courts is the defense, "your honor, the code allowed me to call initialize again, they specifically didn't set it to true." going to fly? Or will you have to prove that the 10 mil you now have was intended to be given to you and your "victim" isn't a victim at all.
> so where does one draw the line between theft and just doing what the code allows? This is the heart of the problem with smart contracts. The theory is that the code is the law. There is no theft. There is no need to trust, authority, or arbitration. Of course, this only works when the smart contracts perfectly meet a correctly defined spec and have no bugs.
It is surprising that people would entrust large amounts of money to Turing complete C-like programming languages in an environment where mistakes are irreversible. Surely you would want to use a language that makes it harder to accidentally introduce common vulnerabilities? For example, considering contracts are likely to be state machines (and the error in this case is a state machine issue), maybe an explicitly st…
There is: https://archetype-lang.org/ with an explicit https://docs.archetype-lang.org/archetype-language/state-mac... feature.
Earlier quoted context omitted.
> these kinds of things won’t happen unless you’re trying something new. Unfortunately, that's probably not going to be what occurs. Even today, there are constantly bugs discovered and fixed, some critical, that have been latent in systems for decades - as in since the last century. The recent FragAttacks against WiFi systems come to mind.
A bug-free version of ProfitSharingRewardPool is much more plausible than a bug-free version of WiFi, or SSL, because the former is less than 1000 lines of code and apparently had an unintended $10M bug bounty.
Serious question for people familiar with this space. Would you encourage an ambitious expert programmer with a substantial finance background to avoid this space entirely, or enter it as a creator, a contractor, or black hat?
For starters, lets pretend like you don't want to be a black hat, because thats a pretty poor way to make money. Not even sure if its lucrative.
For more serious work, either as a contractor or direct hire, there are only a few shops really worth working with/for right now. But they definitely exist. The challenge is their funding streams arent as steady as the market would make it seem. Although they may be doing swell right now they will definitely be hurting when the market turns again. Its a classic world of startups made complicated by even more volatility than the traditional market place for startups.
Despite what HackerNews may believe, this is definitely a space of innovation and future promise. Simply look the numbers, play with some of the major applications, compare it to its traditional variants, and make a judgment yourself. Its hard not to see the potential if you can look deeper than superficial comparisons.
If you really want to go through this route: Read the Bitcoin white paper, research some of the arguments for and against central banking, sound money theories versus lender of last resort and credit elasticity, and money as a memory theory. Then read the Ethereum white paper, play with Metamask and some Dapps, compare the pros and cons with your regular banking or finance experiences, and then start looking at some of the more complex systems and Dapps in the space like Uniswap, MakerDAO, AAVE, and others. At that point, you should have more than enough ammo to see the forest and the trees as you'd like.
Earlier quoted context omitted.
Seems like these smart contacts should include written contracts as well to outline what the code is intended to do, if you can’t rely on the code.
At that point, why have the smart contract? If you want 'automation', just get a trustworthy third party to execute the financials for you , as is already done with (for example) most real estate contracts.
Earlier quoted context omitted.
There is: https://archetype-lang.org/ with an explicit https://docs.archetype-lang.org/archetype-language/state-mac... feature.
Why is this only on tezos? Is there some technical reason why tezos can use it but others can’t. I know tezos was basically born from theDao fallout, but, seems like maybe eth should think about standardization and verification too.
Tezos uses a human readable stack based language as a low level represenation that is suited for formal proofs: https://tezos.gitlab.io/008/michelson.html
If archetype depends on that then its going to be hard to port but i dont think it does.
Another interesting project in development is https://juvix.org/ which targets more backends beside michelson like llvm and wasm. Might run on eth2/Ewasm.
There are also blockchain specific features like: https://medium.com/tqtezos/tickets-on-tezos-part-1-a7cad8cc7...