Blockchain Engineering — Public & Permissioned Chains

Two blockchain projects exploring the architectural tradeoffs between public and permissioned systems — Master's coursework at ASU.

I intentionally worked on both sides of the blockchain spectrum to understand the design tradeoffs, not just the tools.

Public chain: ERC-721 Smart Contract (Ethereum)

Implemented an ERC-721 smart contract on the Ethereum testnet to understand token standards from the inside — ownership mapping, transfer mechanisms, and how application state is enforced through smart contract execution. Deployed using Solidity, MetaMask, and a testnet faucet for test ETH. The implementation was educational rather than tied to a specific use case, focused on understanding how the standard works at the contract level.

Permissioned chain: Supply Chain on Hyperledger Fabric (Go)

Built a Hyperledger Fabric network with Go chaincode for a supply chain scenario. The focus was on chaincode-driven business logic, asset lifecycle tracking, and maintaining a shared ledger among known participants. Assets moved through defined lifecycle stages on a permissioned network where all parties are identified and governed.

Why both?

Public chains optimize for openness and decentralization — anyone can participate, and trust is enforced by consensus. Permissioned systems like Fabric are built for enterprise coordination, governance, and provenance — participants are known, and the rules are different. Understanding that architectural contrast was the core value of the work. The question isn't which is better — it's which is appropriate for the problem, and why.