@howo recently shared with me the image below (neither of us made this image, but I have a reasonable belief that it's copyright free), and it made me realize there are some common misconceptions about 2nd layer apps that are worth dispelling. Originally, I was going to make one post about this, but it started to run long when I tried to avoid skipping any steps in my explanations, so I’ve decided to break it up into a few short, easy-to-digest posts. This also means I won't be explaining all the problems with this image today, either, but hey, what's life without a little anticipation? ![image (3).png](https://images.hive.blog/DQmWapVWwsacyTitpb8oF4XFMDjQDNmvDJUfSj7mPQ5fgyp/image%20(3).png) # Misconception 1: it’s difficult (or impossible) to make decentralized 2nd layer apps Creating a 2nd layer app on Hive is almost trivially easy for an experienced programmer. How easy? Let’s take a look at how to go about creating a 2nd layer app for playing decentralized tic-tac-toe matches. ## Design the transactions and protocol rules for your tic-tac-toe app To start a game, we just need two operations: `offer_match, “player”: “mynextvictim”` `accept_offer, “transaction_id”: transaction_id_of_offer` Whenever a player wants to challenge a player he broadcasts an offer_match. For this simple example, our app will just auto-expire an offer if it isn’t accepted in 24 hours. To accept an offer, the challenged player broadcasts a transaction with the “accept_offer” operation that includes the transaction id of the original offer. If the acceptance is broadcast within the 24 hour period, the app will start a game and accept moves from each player. So we just need one more operation, the “move” operation: `move, "transaction_id":transaction_id_of_offer, “coordinates”: [row_number, column_number]` Again, for simplicity, we’ll design our app so that the challenged player gets the first move, but we could easily make this a parameter of either the offer or the acceptance operation. We just need to add a few more protocol rules: 1) players need to take turns moving, 2) players can’t move to a previously occupied square, 3) player wins if he gets 3 in a row, and 4) game ends in a tie if 9 valid moves occur without a winner (i.e. all the squares get filled). Defining the protocol rules are so simple, there’s probably marginally more work in writing the user interface that displays the tic-tac-toe board, allows the user to click on squares, and updates the board as moves are received from the blockchain. But all of this is pretty easy to do, code-wise. For Hive, two great choices for a programming language to do this would be Python or Javascript, as Hive has easy-to-use libraries that allow your application to publish and read transactions from the blockchain. ## Decentralize your tic-tac-toe game Now, as easy as it was to design, there’s still the “hard step” of decentralizing your tic-tac-toe app, right? Nope, that’s the really easy part. Simply publish the official rules publicly. Ideally, you would also publish your source code with a license that lets anyone run your code. Congratulations, you can play decentralized tic-tac-toe with other people around the world, secure in the knowledge they can’t cheat. Anyone can run your code on their computer, connect it up to a Hive API node, verify all the game transactions, and determine who really won each game (although, fair warning, most of those games are probably going to be ties). The blockchain maintains an immutable record of what moves were actually made, and by whom, so all you need is the publicly available “tic-tac-toe” rules to determine the winner. Someone can run a server that provides false answers, but you can always run your own server to find out the truth.

See: Misconceptions about 2nd layer apps: part 1 by @blocktrades