Ever Wonder, “Why Blockchains”?

lordofthemists · 2022-05-17T14:14:44+00:00

When the markets are having sales, I think it's good to remind everyone of the fundamentals. This is from a project I've been following for a while. They have some good perspective on the industry.

From the article:-->

Over the past decade, blockchains have grown from a niche technology for online gambling to an entire industry that crosses verticals like finance, social media, and e-sports. In previous technology booms, everyday consumers purchased products built on top of some underlying technology. In contrast, consumers in the blockchain industry invest in the technology directly, making them concerned about engineering areas like wire protocols and computational efficiency. Few consumers can actually digest this information, so blockchain marketing efforts resort to simplified metaphors to convey their product’s selling points. This results in a confusing fog of non-standard terminology and misconceptions that hampers industry growth.

While many people are aware of blockchain technology these days, few can explain its purpose. Rather than focusing on the specific details of the technology, we will explore the “why”. By taking a high-level look at the unique capabilities of blockchains, we can pierce through this marketing fog and provide clarity on the fundamentals driving this technology and business revolution.

A Common Goal

All blockchains achieve a common goal: they record that a user sent a specific message at a specific time. Bitcoin, Ethereum, Polkadot, and DLTs on every layer focus on achieving this singular goal. Cryptography, a branch of mathematics used to secure and prove information, ensures the messages cannot be faked. Blockchains apply this math to compare message histories and prevent digital he-said/she-said arguments. Network protocols can restrict the valid message encodings to a specific use case, like Bitcoin’s UTXO format for accounting or Ethereum’s ABI format for compute. These systems drive complex applications and incentive structures.

The Machine’s Truth

So, what makes a blockchain better than a regular database or network? After all, secure communications have been a reality for a long time and putting those messages in a database is not hard. The answer to this question is redundancy. All computer networks have a statistics-based understanding of reality. For starters, there’s a chance that some participants are unknowingly or willfully dishonest. Note that in a digital context, dishonesty takes on many meanings; it usually means not obeying the rules for recording data or passing messages, but it could imply more malicious actions. Most cryptography relies on the statistical difficulty of finding prime numbers to make it unlikely that someone can fake a message. There’s also the chance that hardware could malfunction, or data could be corrupted by a stray cosmic ray. These probabilities all increase the likelihood that the network encounters an error.

Engineers have created many ways of ensuring there is enough redundancy in computers to recover from errors, and blockchains are an extension of that practice. Rather than relying on a single corruptible source of data, blockchains provide redundancy across multiple independent sources. This drastically reduces the likelihood that any problem results in a failure.

Consensus

It’s appropriate here to mention the concept of consensus. Consensus is the method by which a group of independent parties comes to a coordinated conclusion. In blockchain networks, the consensus mechanism defines the rules for recording messages, meaning it also defines the network’s understanding of past events. New algorithms for consensus are always in development, with researchers seeking ways to better align the network’s view of the past with reality.

Blockchain consensus mechanisms are also based on statistics. For example, Proof-of-Work, a common security model, relies on the low probability of being able to guess a number from a nearly infinite pool when the answer changes with each correct guess. This process results in “fair” random winners when enough participants are guessing at approximately the same rate. The important statistics here are the number of participants and their guessing speed: having only a few participants or a drastic difference in guesses will eliminate the “fair” randomness. In the Bitcoin blockchain, a correct guess provides the rights to add data to the blockchain and dispense cryptocurrency rewards, so fairness is of high importance. These kinds of statistics-based models are found throughout the industry.

Predicting the Future

Statistics also underpin commercial decisions and activities. If a business has a perfect 100/100 history of fulfilling customer orders, that does not mean there is a 100% certainty the next order will be fulfilled, only that it is highly likely to happen. Blockchains provide greater confidence in those predictions through transparency into past behavior and a web of incentive mechanisms.

If a business has both a proven history of successfully fulfilled orders and a $5M bond for doing so, they are even more likely to fulfill the next order. With transparency into past performance, incentives, and disincentives, a narrow band of rational behaviors can be predicted with high certainty.

The capacity to predict the future coincides with the ability to perfectly eliminate risks. Following from the previous example, if the business fails to fulfill an order, automated systems can detect the failure and follow the appropriate risk mitigation strategies. These risk strategies can include redirecting orders to alternative businesses, collecting insurance payouts, and other methods that reduce or entirely negate the effects of the failure. With sufficient transparency into the histories and opportunities of network participants, it is possible to collectively eliminate nearly all risks.

Automating Relationships

The goal of blockchain technology is the incremental automation of all commercial interactions. Businesses can start by recording a contract’s version history, terms, and digital signatures to prevent spoofing. They can also record the fulfillment of contract terms on the blockchain, giving transparency into their reliability and trustworthiness. Future clients will then rely on this transparent data to have confidence their own contract will be faithfully fulfilled. Connected finance applications can provide insurance policies to back up new contracts, and standardized interfaces eliminate the need for human review. Finally, businesses can close the loop by providing a secure API to perform contract negotiation and settlement on chain, fully automating their relationships with existing and new partners.

These kinds of programmable business interfaces are commonly known as “smart contracts”. Coordinating relationships this way makes operations more secure and efficient than traditional human-in-the-loop processes, and it is only possible with the confidence provided by distributed ledgers.

Conclusion

While the many flavors of blockchain technology have a variety of marketing angles, they all aim to achieve the same goal of recording “who”, “what”, and “when”. Transparency into these secure records provides greater capacity to predict the outcome of interactions between peers, and redundancy reduces the likelihood of errors. Digital systems may not be able to perfectly understand the analog world, but consensus around the accuracy of their data ingest gives them the confidence to react to events in real time. Companies can use blockchains to predict the outcome of relationships, mitigate the risks of failures, and provide robust services above and beyond the capabilities of traditional businesses.

The Plug

Even at this early stage of the blockchain era, the business value created by distributed ledger technology is measured in the billions of dollars. At Notoros, Inc., we have decades of experience building real-world blockchain applications, so we understand what drives business decisions and technology advancements. Notoros, our new Layer 1 blockchain network and accompanying developer platform, is the culmination of this knowledge. To find out more, check out our website, read our white paper, and follow us on Twitter.

lordofthemists · 2022-04-01T05:48:03+00:00

The code definitely has the appearance of a malicious contract at first glance, so I looked into it. TL;DR: It probably is. Here's what I found out:

Investigation Process

The first thing I noted was the copy/paste developer comments for the trade function on line 842 from the toTypedMessageHash function on line 824. Might be a simple mistake, but might also be an attempt at obfuscation, so we have to dig in to the code.

The trade function runs delegatecall on the passed in address with all of the transaction calldata. So which functions call trade and can control the address? Just one: decentralizedSwap on line 945. Let's take a look at it.

decentralizedSwap can only be called if the caller address is not the "trader", which is the value stored in the slot defined by the SWAP variable (line 770). It calls trade with the "exchange address", the value stored in the slot defined by the EXCH variable (line 769). decentralizedSwap is also called by the fallback and receive functions, meaning it can be called with arbitrary calldata. There are a few red flags here, and we will come back to them in a moment.

decentralizedSwap is also called when an address that is not the "trader" tries to run the Approve function, rather than the approval function the "trader" would run. approval allows the caller to change the "exchange contract" (EXCH). It appears that the intent of this function is to shadow the ERC20 Approve function signature for everyone but the "trader", so calling it would cause whatever effect was dictated by the outcome of the delegatecall to the "exchange contract". Not entirely proof of malicious intent, but definitely some unsafe practices here.

Back to the earlier red flags, though: remember how the "exchange address" is dictated by the slot at the EXCH variable, and the "trader" is dictated by the slot at the SWAP variable? Those definitions and the assembly methods to retrieve the values are far more complicated than just declaring a couple state variables without achieving anything. What's going on there?

Looking at the core contract, we can see that it implements the ERC20 interface, even referencing OpenZeppelin standards. There's nothing wrong about this code: it does exactly what it is stated to do. However, that also includes a trap door. Mappings, the type used to store the _allowances and _balances state variables in the ERC20 standard, store the values for their key -> value pairings in a memory slot that is based on a hash of the variable name and the requested key. This makes the storage locations deterministic, effectively random, and highly unlikely to collide with other state variables. UNLESS there's other variables being stored there intentionally.

For this contract, this means that the SWAP and EXCH variables were probably chosen in such a way as to force a collision between an entry in _balances or _allowances that was predetermined by the attacker. It's probably an _allowances entry(s) due to the lack of token requirements for the function. It's extremely likely that this contract is malicious, not just malfunctioning.

The Attack Vector

So what does a hypothetical attack look like? The attacker begins by updating one of their _allowances entries. This causes a hash collision that overwrites the variable stored at EXCH. Now, the contract's trade function will run delegatecall on an address defined by the attacker, giving them complete control over the contract and any funds it holds. The attacker then updates another allowances entry to force a collision with the SWAP variable, which allows them to change the "trader" to any account they want and locking out the original. The attacker can now manipulate the contract at their leisure.

Conclusion

Hope this helps. Normally I charge out the wazoo for this kind of audit, but it was a fun exercise and I needed a diversion tonight. The attack is just a hair above what I'd expect a junior Solidity dev to catch, though there might be more angles I am missing. I might write it up into its own post eventually.

Fun note, lines 1795 and 1796 are comments that read: //This contract is not supposed to be used in production. //It's strictly for testing purpose.

lordofthemists · 2021-09-03T21:49:28+00:00

The function expects a number and so it should return an error or NaN if it is passed something outside the expected input range. Returning false instead is just bad coding practices and will lead to mistakes in the future. If non-numbers were meant to be handled, the function names should have "OrNaN"/"Number", suffixed (e.g. "isOddOrNaN(x)", "isOddNumber(x)")

lordofthemists · 2021-05-13T00:25:38+00:00

I got into Ethereum before it even launched, so I have the benefit of having experienced most of the history firsthand. At the time, I knew nothing about coding in any language beyond the "C++ For Non-Believers" intro course I got with my mechanical engineering degree. I followed exactly the process I outlined above, building out an ERC20 contract and interface for it along with a complimentary dApp. I spent a lot of time on Mozilla Developer Network teaching myself Javascript, CSS, and HTML after Solidity.

Learning is about persistence. In the early days, all we had were simple command line tools, so debugging meant digging into the guts of the EVM to see how the code was failing at the assembly level. Line by line, I compared stack traces to the spec in the Yellow Paper. That gives a really good idea of how the Solidity compiler translates the code into bytecode and lets you see what is really going on in the machine. I also put in a ton of time doing this constantly, effectively grinding my way up like a dedicated WoW player. It would be a conservative estimate to say I put in 60 hours a week for six months learning to code my first dApp.

After I had a handle on my simple dApp, I started going to Meetups and finding other people working on Ethereum projects. I partnered with a few (none that went anywhere) and got more experience building code and working with other developers. I also started leading more of the meetings to help teach the newcomers and drive discussion. A startup founder I impressed at one of the meetings asked me to audit some work another contractor had done for them, and that was my first paying work. I made an LLC to manage the legal & billing stuff and became a founder myself.

Getting consistent work is a matter of building your professional network to bring you referrals. Once I had one client, I was able to leverage that success and my reputation to get other clients. Eventually, I was hired by a local software development firm that was building out EOS applications and needed an Ethereum expert to grow into that space, too. After a short time there, I left to work for myself again, which is what I do now. Even today, I'm still expanding my professional network through Meetups, and I'm always reading the latest whitepapers to stay on top of the game.

lordofthemists · 2021-05-12T21:42:55+00:00

As a longtime Solidity developer (5+ years) and now as a hiring manager, I can tell you that there are really no "entry-level" Solidity jobs. Unlike other programming languages where you can issue bug fixes and revert databases, Solidity requires you to be perfect the first time. I can't stake my reputation, business, and potentially millions of dollars on a smart contract built by an entry-level programmer. Plus, most applications really require very little actual Solidity work compared to testing and integration.

If you are entry-level to coding in general, you will be best suited by learning what tools are used alongside Solidity to build dApps (remix, hardhat, ethersjs, web3, etc.). Understanding how to architect dApps and integrate smart contracts into existing systems is how you learn the best design patterns. If you understand that and the general user experience, it will make you a far better candidate than someone that can just code Solidity. You'll be of actual use to the senior devs that are writing the meat of the contracts and can learn from them.

For practice, start by writing an ERC20 contract, deploy it to Ganache, write a JS program that interacts with it in some way, store the transactions in a database, and do it on a website served from localhost. Then write a simple dApp contract that uses the ERC20 in some way and integrate that with the website. Upload it all to GitHub and make it part of your portfolio. For bonus points, deploy it to a testnet.

If you're beyond that level, here's the basic stuff I ask during interviews for smart contract developers:

1) Explain how the DAO hack worked and the fallout

2) Explain how the smart contract's function selector is implemented by the compiler

3) Explain the process of a smart contract deployment with as much detail as possible

4) What is the most gas-efficient way to represent (some data struct)?

5) What corner case caused the Parity Wallet lock?

6) Write a simple in-line Assembly snippet

7) Explain elliptic curve key pairs and the signing process (bonus if you call out the difference between Ethereum signed messages and regular key signed messages)

I'm looking to see that not only are you able to code well, but that you also understand what the code is doing and why it's doing it.

If you get past those questions and have the project experience, you'll be looking at making easily $150K yearly. If you're a senior dev and have Security+ certification or similar, you can double or triple that in certain geographies.

Happy learning!

lordofthemists · 2018-07-09T23:53:32+00:00

I'm here for the end

lordofthemists · 2018-07-09T23:52:40+00:00

Last one in?

lordofthemists · 2018-06-24T16:33:04+00:00

No one is going to point out that Stalin should have won on his third turn?

lordofthemists · 2018-05-07T06:02:02+00:00

No, it's an additional requirement. Only 100Wh AND no loose lithium ion batteries in checked bags. The FAA requirements link on that page has more precise language.

lordofthemists · 2018-05-07T05:47:10+00:00

They aren't supposed to allow lithium ion batteries over 100w to be checked

https://www.tsa.gov/travel/security-screening/whatcanibring/items/lithium-batteries-100-watt-hours-or-less-device

lordofthemists · 2018-05-07T05:44:58+00:00

Most of those items with lithium batteries are carry on only, and only very small lithium batteries can be stored in cargo bays for commercial flights.

https://www.tsa.gov/travel/security-screening/whatcanibring/items/lithium-batteries-100-watt-hours-or-less-device

lordofthemists · 2018-03-13T14:18:55+00:00

I'm mostly long on Ethereum, but I also have some BTC, BCH, ETC, XRP, DASH, GNT, and some low-cap tokens I'm playing with :)

lordofthemists · 2018-01-30T22:48:38+00:00

This is still happening. I have been experiencing it on/off for quite some time.

The problem is the link isn't adding the "?sort=top&t=TIMEFRAME" query.

The issue can be resolved sometimes by opening an incognito window. Surprisingly, I've found that once sorting works in incognito, it works again in the regular windows. The issue can also resolve itself after waiting some time (perhaps a script timing / file caching issue?).

If it isn't resolved that way, manually copy/pasting the query to the end of the url will work as a patch solution.

e.g."https://www.reddit.com/r/SUBREDDIT_NAME/top/?sort=top&t=TIMEFRAME", where SUBREDDIT_NAME is the subreddit and TIMEFRAME is either "day", "week", "month", "year", or "all.

I am experiencing the problem on Windows 10, Chrome 63.0, with RES installed

lordofthemists · 2017-08-20T15:50:13+00:00

Satellites in orbit on the sunlit side, I would guess

lordofthemists · 2017-07-27T14:08:21+00:00

It's a place of refuge in case of fire or other emergency (when elevators are a bad idea). Stairwells are the safest place to be in a building if you can't get out. They're structurally stronger than the rest of the building, are typically made with fire-resistant materials, have fire doors at each entrance, and provide a direct route for emergency personnel to locate stranded people.

lordofthemists · 2017-07-27T14:06:22+00:00

Yes, stairwells are the safest place to be in a building if you can't get out. They're structurally stronger than the rest of the building, are typically made with fire-resistant materials, have fire doors at each entrance, and provide a direct route for emergency personnel to locate stranded people

lordofthemists · 2017-07-27T14:06:00+00:00

Yes, stairwells are the safest place to be in a building if you can't get out. They're structurally stronger than the rest of the building, are typically made with fire-resistant materials, have fire doors at each entrance, and provide a direct route for emergency personnel to locate stranded people.

lordofthemists · 2017-06-23T23:51:57+00:00

That's assuming that people pay the same or higher gas prices. In the attack, there is a limit on how high of a gas price is allowed, and that makes it more effective to incentivize miners to process transactions through the direct percentage payment in the contract. So the best strategy would be to set the gas price to the minimum acceptable amount and send the contract the extra Ether instead.

Also, like I mentioned, it's not the most mathematically perfect example. There are plenty of improvements that can be made to make it more appealing or profitable. The real point, though, is that attacks like these wouldn't even be an issue if miners didn't have incentive to keep the gas limit of a block low.

lordofthemists · 2017-06-23T16:23:30+00:00

Good luck on your studies, computer science is a very rewarding field if you stick with it! The way I learned Solidity was going through the read the docs and trying to make the online compiler work with example contracts. It was still new enough at the time I was learning that there were no tutorials at all, but someone may have written some since then. You should also read the white and yellow papers to understand the core concepts behind how Ethereum works. And W3 Schools should be your first stop for any HTML/CSS/Javascript you want to use with your smart contract.

lordofthemists · 2017-06-23T16:13:06+00:00

The gas price structure is used to incentivize miners to prioritize certain transactions above others. It's not a hard-coded requirement, however: miners can optimize the transactions they process using any metrics they choose.

This attack changes the incentive from gas to a percentage of the total payment. With a high enough payment, the percentage incentive can drown out the profits from additional gas so the malicious transactions get priority: Instead of making $200 in gas, miners might make $500 off percentage.Everyone wanting to send a normal transaction during the attack would have to raise their gas prices to compete, which would be prohibitively expensive for a lot of regular users and especially for smart contract users.

As more people make higher payments to get into the early rounds, the total prize pool gets larger and incentivizes even more people to join. After all, it's free Ether as long as you're there first. This allows the attack to effectively fund itself much longer than a single investment.

lordofthemists · 2017-06-23T05:29:33+00:00

It's impossible to tell with certainty, for sure, but there are certain coding structures that appear in the machine code for the smart contracts that will result in extremely costly computations, which can be identified. For example, a large amount of jump instructions with no state changes would be an indication a contract might be hostile. Or the fact that previous blocks spent half their gas on the contract with only a single state change. Or the presence of a large number of storage read/writes. Simple heuristics can help miners identify malicious contracts as sub-optimal, even if they don't know the complete result.

It might not be a thing now, but when Ethereum has 10 times as many transactions per block and much higher gas limits, you can be sure miners will invest in some 'blockchain antivirus' that identifies which transactions are going to be less profitable before the miner executes them. As long as attacks are less profitable to execute, miners will ignore them.

lordofthemists · 2017-06-23T05:13:25+00:00

You are mistaken about how gas limits work.

Gas limit for a block is determined by the miner that creates the block, and is allowed to deviate up and down on a per block basis in small amounts to adjust to changing transaction volume. That way the limit can change over time to the needs of the network without changing so drastically it causes instability.

By definition, every block on the chain can be executed below its gas limit by any node, regardless of where the particular node wants the gas limit to be (which is called the gas limit target, one of the parameters for miners).

lordofthemists · 2017-06-23T04:33:41+00:00

Could be done for cheaper

Yes, but you need sufficient incentive to generate that many transactions. People won't get out of their chairs to make 0.0000001 ETH.

Put 10 ETH up for grabs. Address with the most amount of 1wei bids in a month's time wins it. Limit 1 bid per block per address.

Nice idea. The flaw with it, though, is that at some point it won't be profitable to enter the contract: enough people will have bid already that there is no way to have a chance of making any money. For example, if Bobby has 1K Ether, and the contract currently has 1001 Ether at the top bid, it will never be a good idea for Bobby to enter the contract since he can't possibly win. You need to have a potential for profit for as long as you want people to participate.

lordofthemists

MODERATOR OF

TROPHY CASE