Merge pull request #16112 from qbzzt/250822-ori-blurb

Add links to my portfolio

Author: wackerow

public/content/developers/tutorials/all-you-can-cache/index.md

@@ -861,3 +861,6 @@ The code in this article is a proof of concept, the purpose is to make the idea
   There are ways to solve this problem, and the related problem of transactions that are in the mempool during the cache reorder, but you must be aware of it.
 
 I demonstrated caching here with Optimism, because I'm an Optimism employee and this is the rollup I know best. But it should work with any rollup that charges a minimal cost for internal processing, so that in comparison writing the transaction data to L1 is the major expense.
+
+[See here for more of my work](https://cryptodocguy.pro/).
+

public/content/developers/tutorials/creating-a-wagmi-ui-for-your-contract/index.md

@@ -580,3 +580,6 @@ Of course, you don't really care about providing a user interface for `Greeter`.
 1. You can [add Rainbow kit](https://www.rainbowkit.com/docs/installation#manual-setup).
 
 Now go and make your contracts usable for the wide world.
+
+[See here for more of my work](https://cryptodocguy.pro/).
+

public/content/developers/tutorials/erc-721-vyper-annotated-code/index.md

@@ -710,3 +710,6 @@ For review, here are some of the most important ideas in this contract:
 - Past events are visible only outside the blockchain. Code running inside the blockchain cannot view them.
 
 Now go and implement secure Vyper contracts.
+
+[See here for more of my work](https://cryptodocguy.pro/).
+

public/content/developers/tutorials/erc20-annotated-code/index.md

@@ -927,3 +927,5 @@ For review, here are some of the most important ideas in this contract (in my op
 
 Now that you've seen how the OpenZeppelin ERC-20 contract is written, and especially how it is
 made more secure, go and write your own secure contracts and applications.
+
+[See here for more of my work](https://cryptodocguy.pro/).

public/content/developers/tutorials/erc20-with-safety-rails/index.md

@@ -210,3 +210,5 @@ This is a cleanup function, so presumably we don't want to leave any tokens. Ins
 ## Conclusion {#conclusion}
 
 This is not a perfect solution - there is no perfect solution for the "user made a mistake" problem. However, using these kinds of checks can at least prevent some mistakes. The ability to freeze accounts, while dangerous, can be used to limit the damage of certain hacks by denying the hacker the stolen funds.
+
+[See here for more of my work](https://cryptodocguy.pro/).

public/content/developers/tutorials/ethereum-for-web2-auth/index.md

@@ -883,3 +883,5 @@ There may be a solution using [multi-party computation (MPC)](https://en.wikiped
 
 Adoption of a log on standard, such as Ethereum signatures, faces a chicken and egg problem. Service providers want to appeal to the broadest possible market. Users want to be able to access services without having to worry about supporting their log on standard.
 Creating adapters, such as an Ethereum IdP, can help us get over this hurdle.
+
+[See here for more of my work](https://cryptodocguy.pro/).

public/content/developers/tutorials/ipfs-decentralized-ui/index.md

@@ -69,3 +69,5 @@ Additionally, some packages have a problem with IPFS, so if your web site is ver
 ## Conclusion {#conclusion}
 
 Just as Ethereum lets you decentralize the database and business logic aspects of your dapp, IPFS lets you decentralize the user interface. This lets you shut off one more attack vector against your dapp.
+
+[See here for more of my work](https://cryptodocguy.pro/).

public/content/developers/tutorials/merkle-proofs-for-offline-data-integrity/index.md

@@ -248,3 +248,5 @@ Looking for example at [Optimism](https://public-grafana.optimism.io/d/9hkhMxn7z
 In real life you might never implement Merkle trees on your own. There are well known and audited libraries you can use and generally speaking it is best not to implement cryptographic primitives on your own. But I hope that now you understand Merkle proofs better and can decide when they are worth using.
 
 Note that while Merkle proofs preserve _integrity_, they do not preserve _availability_. Knowing that nobody else can take your assets is small consolation if the data storage decides to disallow access and you can't construct a Merkle tree to access them either. So Merkle trees are best used with some kind of decentralized storage, such as IPFS.
+
+[See here for more of my work](https://cryptodocguy.pro/).

public/content/developers/tutorials/optimism-std-bridge-annotated-code/index.md

@@ -1353,3 +1353,5 @@ These bridges typically work by having assets on L1, which they provide immediat
 When the bridge (or the people running it) anticipates being short on L1 assets it transfers sufficient assets from L2. As these are very big withdrawals, the withdrawal cost is amortized over a large amount and is a much smaller percentage.
 
 Hopefully this article helped you understand more about how layer 2 works, and how to write Solidity code that is clear and secure.
+
+[See here for more of my work](https://cryptodocguy.pro/).

public/content/developers/tutorials/reverse-engineering-a-contract/index.md

@@ -740,3 +740,5 @@ So it looks like a `claim` variant that claims all the windows.
 ## Conclusion {#conclusion}
 
 By now you should know how to understand contracts whose source code is not available, using either the opcodes or (when it works) the decompiler. As is evident from the length of this article, reverse engineering a contract is not trivial, but in a system where security is essential it is an important skill to be able to verify contracts work as promised.
+
+[See here for more of my work](https://cryptodocguy.pro/).