Project & Development Update #16

December 5, 2022

Good afternoon, pilots. We're back! Pop the champagne and grab your reading glasses, because the next update is here.

We'll start off with a quick list of general progress and team focuses. From there, we'll dive into some spicy audit news and detail some bleeding edge tech upgrades for the smart contracts. About one eternity of reading later, we'll share tons of GUI sneak peeks and in-game features for your enjoyment and input. We can't wait to hear what you think! Last but not least, we'll share an update from our beloved The Learner

Bonus Join us on Discord in 20 Minutes for a Live Team Q&A here within the server. We'll be taking questions from you guys related to today's new update, and anything else in general.

Let's dive in. 👇

🔹 Progress

• Onboarded additional pixel artist to the team
• Onboarded PhyzixTeacher to the core team as project manager
• Brought the team onto Linear for improved management and organization

• Revamped the construction bay to use ZK proofs
• Upgraded random oracle to use VRF v2
• Created additional documentation for the contracts repo
• Completed two rounds of Macro audits and fixes
• Set up continuous deployment for all deployable repositories
• Created player profiles backend
• Updated the yellowpaper to cover the ZK construction bay (pending edits)
• Updated CAIS in preparation for onboarding
• Completed and packaged proposal quality model
• Completed the asteroid belt generation algorithm

• Completed additional GUI modals
• Completed additional promotional material for marketing
• Created in-game player avatars
• Created in-game ship propulsion animations
• Revamped frigate and interceptor ship art for all manufacturers

• Moved into Citadel Gaming House v3 (larger office!)
• Hate to do this, but we crushed a lot of special stuff that will have to be covered in future updates!

🔹 Remaining Focuses

• Completing the GUI
• Completing the construction bay frontend
• Completing the day zero proposals
• Completing remaining special things that will be covered in future updates
• As before, continuing to tie everything together and polishing

🔸 Macro x Citadel Round 2

Audit Results

Earlier this week, we completed our audit process with Macro. We’re thrilled to share that we’ve received their final report and have successfully passed another audit gauntlet.

This report covers:

• Sick new contracts
• Dank modifications and upgrades since our previous audit with Solidity Finance
• Rad gas optimizations

As before, and as always, you can find the full report here.

Team Reflections

This time around, we're extremely satisfied to share that our contracts did not pass on the first try, which was the exact outcome we wanted when committing to undergo a second audit.

We were fortunate to work with a team of six extremely talented auditors from Macro. Over the last twelve weeks, they spent thousands of hours reviewing fifty contracts, delivering seventy-four (!!!) findings, and providing countless valuable insights. The number of findings alone is a testament to Macro’s attention to detail and commitment to quality. They more than live up to their claim of catching issues that other auditors miss.

For those curious, here's a quick summary of their findings by category:

Critical - 1
High - 9
Medium - 17
Low - 18
Code Quality - 21
Gas Optimizations - 6
Informational - 2

Throughout the process, we were incredibly impressed by their communicative and attentive approach. It felt like our teams were working together as one unit rather than two separate entities. It was immensely gratifying to be able to push the project to new heights.

As soon as any questions or concerns arose, they responded quickly and professionally which kept us feeling secure throughout the entire process. On top of that, we partook in weekly meetings which were not only fun but kept both teams locked in sync.

TL;DR Macro exceeded our expectations. They are incredibly impressive and exactly what we wanted for the project and the DAO.

Updated Costs

When we began our audit process with Macro in September, the scope estimate was approximately 5 weeks.

However, as we were furthering our own research into tech advancements in the field, we saw a great opportunity to more efficiently execute our vision for what our contracts could be. With Macro’s support, we felt confident that we could make it happen.

This meant rebuilding the construction bay contracts from scratch with zero-knowledge proofs, upgrading to VRF v2, tidying up several contracts, and making improvements all around the codebase. We believe that these changes were extremely beneficial to have before launch.

As a result of our upgrades, the scope of the audit increased, and the cost of the audit rose to $225,000. However, because we had previously communicated that the cash cost would be ~$100,000 split between the core team and The Citadel DAO, we felt that we should honor the original pricing for the DAO.

To do this, the core team has contributed an additional $100,000 to cover the cost of the scope increases. We are confident that this expense will be well worth it for the project and the community.

🔸 Zero Knowledge Construction Bay

What is it?

The construction bay is the contract that introduces new ship supply. Every week, it holds a blind auction for a set number of ships, where every winning bidder pays the same price. Initially, it required an off-chain service to validate and order bids. With the ZK construction bay, we have brought all bid validation and ordering onchain and eliminated the need for an off-chain backend.

How it works

Because ship auctions happen onchain, it is difficult to natively hide participants’ bids.

Previously, our solution was to keep deposits onchain and bids off-chain. For security, we required a signature from our backend and a signature from the participant on each bid ticket before it could be revealed. The backend could then validate that each participant had a large enough deposit before signing their bid ticket. Because there was no economical way to forcefully reveal everyone’s bid, the backend also had to be involved in submitting the winning bid.

This created a couple hypothetical points of centralization: the core team could manipulate the backend to prevent it from signing certain bid tickets or to submit an inaccurate winning bid. These issues were partly circumvented because governance could revert the results of the auction and punish the core team. However, it obviously would have been better if they didn’t exist at all.

We built the ZK construction bay to eliminate these issues. Using zero-knowledge proofs, the construction bay is now able to validate that participants’ bids are valid, without knowing the content of the bids themselves. Storing the hashed bid that each participant submits ensures that participants keep their commitment and do not change their bids before reveal. In addition, keeping track of bids as they are revealed provides the information required to select the winning bid. Together, these steps eliminate the need for an off-chain backend along with its points of centralization. With the ZK construction bay, validation is moved directly into Solidity, making it more transparent and directly modifiable by governance.

Why it's important

The construction bay is the main way that new ship supply is brought into the game. It has a huge impact on the ship economy, and consequently we want it to be as secure and decentralized as possible.

While we’ve provided the community with the tools to hold the core team accountable in preventing abuse, it’s obviously better if we can remove this potential altogether. That's exactly what the ZK construction bay does. It adjusts the ordering of the auction phases and uses ZK tech to ensure that anyone who can produce a valid proof can submit and reveal a bid, and that the winning bid is selected using onchain data, without any external input.

By bringing everything onchain, we have eliminated a point of centralization, reduced future server costs, and placed more of the project directly in the hands of the DAO.

Note: If you're curious to learn more about zero-knowledge proofs, feel free to use this site as a resource: https://chat.openai.com/chat

Future Use Cases

Throughout this process, we've learned a lot about zero-knowledge technology and how to apply it to our work. We're really just scratching the surface of potential use cases for ZK proofs, and we believe they'll play a critical role in the future of The Citadel as we continue to explore the boundaries of what's possible in an onchain game.

🔸 GUI

Functionality Showcase

The Citadel will launch as a Minimum Viable Game (MVG). In that vein, the GUI has been optimized above all else to be efficient and intuitive. The design balances visual simplicity and exposure of the game's underlying strategic depth. At the same time, it remains easy for community developers and designers to build upon.

Rather than hit you in the face with repetitive window descriptions, we've labeled the internal components directly and compiled them into individual embeds below for your viewing pleasure. We've also added personal footers on a few embeds to highlight some of the in-game features that we're most excited to share.

For context, these windows sit on top of the star map and function similar to a computer desktop. Players may open windows and position them in the way that makes most sense for their playstyle. The goal is to provide clear, at-a-glance information while keeping a clean, uncluttered look

Feedback is welcome and highly encouraged on anything you see here, so feel free to ping us in chat or ask questions on whatever you're curious about!

Ship Info

Region View

Asteroid Belt Info, Ship Manager, Combat Log

Mining Ledger

Roaming Ledger & Kill Report

To add some spice to the marauder lifestyle, we've updated the roaming ledger to display logs of all player interactions.

This means that when a marauder destroys a ship, both players will be able to see the victim, the culprit, and the reason for the destruction. We've also added kill report exports so that you can gloat and/or whine about what's happened to your ship on Twitter and Discord.

Player Inventory

Pilot Profile

When viewing a player's profile, you'll be immediately presented with a log of their game and governance activity, inspired by Nouns. Our idea here was to integrate governance tightly into the social fabric of the game. We're excited about the idea that you might group with player because of their opinions on governance, or vice versa.

Directly below, you'll find their custom biography. We've made these fully editable, in hopes that people will use them creatively. We're especially looking forward to seeing pilots carry on the tradition of salt farming. For inspiration, here's an excerpt of Fleet Commander's old EVE bio.

In-Game Avatars POC (WIP)

With the extra time that we've had during the Macro audit, we've focused heavily on incorporating more social elements into the Citadel launch experience.

As a part of this, we've been exploring a proof of concept for pilot avatars. Players will select their avatars and customize them with a variety of backgrounds, as a means of extending their in-game identities. The idea is that these avatars will help players identify and connect with each other more easily and more personally.

To be clear, these will not be paid PFP NFTs because that is lame. They will be completely free for all players to use in-game. Still, we want to make sure each avatar says something about the player using it, so we're considering a variety of ways that access can be gated, including through gameplay achievements, DAO participation, and ship ownership. For example, you might only be able to use a manufacturer-specific avatar if you own one of their ships. Feel free to give us your thoughts on this topic!

In-Game Ship Propulsion (WIP)

Our goal for The Citadel is to feel as immersive as possible, and one step we've taken in this direction is upgrading ship art with unique propulsion animations. Players will be able to see these animations not only on their own ships, but on ships owned by other players visible on the starmap and in future marketplaces. Our artists really outdid themselves with these animations, and we're excited to see them help bring the Citadel universe to life.

Hangar Concepts (WIP)

As part of our continued focus of enhancing the in-game social experience, we’ve been exploring a concept for creating in-game player hangars to display ship collections. This could be expanded to include in-game player corporations that would incorporate ships owned by your friends with your own ships.

Although this won't be available at launch, we've included a few concept designs below. It's something we're eager to develop and collaborate on with the community after launch.

Region Banner Sneak Peeks

Let your eyes drift off into the beautiful and endless abyss of these handcrafted region-specific banners to explore the unique themes and lore of each region.

🔹 Asteroid Belt Generation Model

We’re proud to announce that we have completed our belt generation algorithm. Throughout the month, we worked with several prototypes before settling on a final implementation. In this section, we’ll give a little insight into that process.

Normally, this kind of algorithm shouldn't be especially difficult to write, but our case was a little bit unique. Specifically, we wanted it to have several nearly contradictory properties. In order to be suitable for production, we knew that model would need to be:

(a) Unpredictable: it shouldn’t be obvious to players where and when new belts appear
(b) Managed: a region shouldn't have too few or too many belts for too long
(c) Stable: a region's next state should be related to its current state
(d) Robust: the algorithm should still work if players are distributed differently than we expect
(e) Smooth: configuration should be simple, and it should be possible for regions to be in many different states

The goal was to write the simplest algorithm that satisfied all of these constraints, and that could ideally be eventually verified on chain.

We started with a simple implementation that accepted inputs for the target number of belts in each region, and then monitored the actual number of belts in each region. On each run, it would select a random number and a threshold for each region. If the random number exceeded the threshold, it would generate additional belts. The algorithm would balance each region by selecting a lower threshold for belt counts below the target and a higher threshold for belt counts above the target.

This implementation had almost all of the properties we needed, but was not adequately managed or smooth. Both of these issues stemmed from the fact that it wasn’t possible to specify a true mean number of belts in each region. Because the target was not the mean, distribution of belts was not actually centered around it, and the algorithm had a tendency to rapidly spawn a belt immediately after a belt was depleted. Under these constraints, achieving balance was not straightforward.

After some thought, it became apparent that this algorithm was critically flawed: the probability that any number of belts existed in a region was not only dependent on the probability that fewer belts existed, but also dependent on the probability that additional belts existed. Put simply, all parts of the system were reliant on adjacent parts of the system.

Seeing this problem, we attempted to model the system as a nonlinear set of equations and throw a solver at it. This is the default approach when you are faced with a hard problem with no clear solution. Unfortunately, this attempt failed miserably when the solver could not find a solution. This was pretty astonishing, because these solvers are highly optimized and can solve some of the hardest problems. Generally, when a nonlinear solver fails, you need to remodel the equations to make use of some symmetry of the problem.

Finally, we decided to try to make use of evolutionary algorithms. These algorithms work by repeatedly "reproducing" code that optimizes well, while "killing off" poorly optimizing code. They tend not to work very well, and so it was pretty surprising when they beat the nonlinear solver and were clearly viable. Our final algorithm accepts the mean and standard deviation for belt counts in each region and periodically generates belts according to a true normal distribution. We’re extremely happy with the result, and believe that it will work well in production.

🔹 One Year

As of last week, it has officially been one year since development began on The Citadel and we opened up the server. Without a doubt, building out in public has been the best decision we ever made for the project.

Although it's been a minute since our last official update, we've actually been working harder than ever. Not only has the team grown, but we've made substantial improvements to our internal organization and efficiency thanks to using Linear and having PhyzixTeacher join the team as project manager!

Moving forward, our goal is to put out routine project updates around the start of each month. The next few updates should be pretty rad and we're super excited about them, but they'll have to wait until the time is right.

Thank you for your continued patience, support, and kindness as we move forward in creating The Citadel. The community is a constant source of inspiration and motivation for the team, and we couldn't do it without you guys. We are grateful for each and every single one of you.

Bonus We've added as a server emoji. Not only does it double as representing your face after you've read through this entire update, but it's also great for expressing how the Web3 community makes you feel!