Oddlung

・Purpose of the Application

The problems and reasons for the deadlock in web2 today are as follows.

The first problem is the endless collection of user data by app operators, and the second problem is the "curse of the free millennium" users' refusal to pay for web services. In fact, these two problems are cross-referenced.

The goal is to break the illusion that Web services are free of charge, and to foster a willingness among users to develop their own charged services. Our goal is to help users overcome the difficulties they face on Web2 by first becoming "self-governing" themselves, rather than complaining about the collection of personal information.

The specific method is to let the user's creation, i.e., the content itself, rather than the user, self-govern the platform. This does not mean that the content itself has a will, but rather that the attributes of the content are indexed and ranked in a pecking order to "automatically" provide fair autonomy.

With this application, all "divisible things" in general can be reconstituted in a decentralized manner without resorting to authority. That is, it is possible to form a new "Beatles" that everyone can agree on from among all the band members in the world, or to create the best hamburger in the United States by decentralized collection, selection, and selection of the ingredients to be sandwiched together.

Oddlung allows for relative evaluation of areas such as "artistic activities" and "personal preferences," which are difficult to evaluate in absolute terms, while skillfully avoiding tampering, invasion of privacy, and other risks in terms of ethics.

What sets Oddlung apart from the numerous DAOs and other systems that promote autonomy in the world is that it assumes an environment so harsh that only crackers exist within the app. There are three main types of crackers that will appear in this app. We will show how to get rid of these nuisances after we look at the specifics of the app.

1. $1 Big-Name Problem: High-profile person offering fewer coins.
2. Got's Talent Problem: Low-skilled amateurs with big capital background.
3. Byzantine Art in General Problem: 51% attack by performers.

・Specifications of the application and specific usage for the current situation.

In order to achieve the kind of content-based platform autonomy that we have been talking about, you first need a place to store the content. It must be decentralized and managed, of course. At the same time, an important procedure for self-governance is the election of a leader. The platform for doing this needs to be seamlessly connected to the content repository. For cooking on a large scale, you need a food storage first, right? It is the same thing.

Therefore, this application combines two different applications to form a single application.

One is to imagine a virtual aquarium within a mapped area. It uses blockchain, but it is not just an IPFS.

The other is a system for leader election and self-governance where content plays the role of personal identity. Water" as a content repository and "Green" as a symbol for leader election and preservation of the commons, both of which complement each other to form a single application.

First, let us explain the first application, "Water".

First, a virtual giant water tank (a.k.a. BigWater) the same size as your home or office is installed underground.

Inside the tank, your personal creative content floats as paper darts.

The dart is a UTXO that can be created by anyone in the house/company, and the amount of coins (Charm) attached to it is, so to speak, the self-assessment amount for the idea (and contents). It is to set the value at your own discretion, remembering how much the (self-created) content is worth.

・Detailed information on how to use the /create application

In /create, you can define your own area called "water". A device called a "dart" can be placed in this area, which is loaded with tokens or NFTs to make it move in a linear motion. When the dart collides with a panel, it changes direction according to the laws of physics. The panel that is shortest toward the head is called the "upPanel" and the panel that is up after impact is called the "downPanel. When colliding with a panel, the dart sends its path from up to down as Path data, but the path data is temporarily stored in the panel's memory, so the dart does not keep the path it has followed.

What happens when a dart collides with another dart?

When a dart collides with another dart, a contraption called depth is generated. Clicking on the blue marker in the area will display the contents of the two darts that have just collided. This is based on the absolute rule that governs the entire application: only the stationary dart is visible.

/leader/depth/{depthId} You can create objects called "pegs" to link the contents of each dart to this content. To do this, you must create at least one dart in some area. The act of adding this peg will eventually be able to be generated simply by "viewing the content".

This is the content version of a voluntary liquidity pool. It is tokenized, but that is only to pay for expenses and for self-assessment of one's own content.

These are the general details of the first application, Water. The main benefit of the application so far is to present a way to distribute content on your own virtual space, but with only these features, it is hard to understand why you would want to add a token, which is money, to the dart, right? The real benefit of Oddlung can be seen when it is connected to the other app, Green.

The next step is to select a leader from the content associated with each of its darts. From here it connects to the second app.

/leader/altitude/{altitudeId} Where you typed Peg earlier, i.e., the Depth object, under certain conditions, you can create an "altitude" object on top. altitude is used to select a leader for the content.

・Reader election procedure

/content/{contentId} Leaders are elected in this order. Of these, only "crowning" can be manually operated by the user. Leader election is performed in the following order "peg=>candidate=>crowned=>kick=>monolith"

(1) Peg: When two darts collide, the content owned by the two darts will be temporarily opened to the outside world. The general public can link to either of these contents with their own Dart contents. This operation is called "pegging," and the winner is the dart that has the most pegs between the two darts that have collided.

The winner is the "kicker" and the loser is the "coordinator. The kicker tosses a coin called a "kicker coin" to the coordinator.

(2) Candidate: In the "Candidate" category, the contents of the same "type" as the coordinator are collected. You can define it by yourself depending on your task or role, or you can follow the definition of others.

・How are coordinators selected?

On second thought, being a coordinator is more beneficial than being a crown. Because as a coordinator, you don't necessarily have to create good content, but more than that, you have the right to make decisions for the crown and earn coins. It also means that only the coordinator can censor the entire game.

To be chosen as that coordinator, you must be the person who saved the dart path data in a transaction called "area mining". The content of the coordinator is basically not disclosed for privacy reasons, and only the type of content is presented, like the interface on the game.

(3) Crowning: Once it is closed, it is "crowning" time. The coordinator chooses one of the candidates with alternative content to his/her own as the "crowning" candidate.

The coordinator receives a reward in coins according to the attractiveness of the chosen candidate's content and leaves now.

In the unlikely event that the coordinator does not select the Crown, the Dart with the highest intra-diversity index among the Candidates will be selected as the Crown.

(4) Kicking: When kickercoin is passed to the next coordinator, the coordinator is notified, and if he/she fills in the input key, he/she is approved and the next coordinator is selected.

・Description of each index (UT, WTC, KickerCoin)

In leader/ Each object is generated by arranging them in this order. When the Depth contract is created as a result of the collision of the two darts and RubberCoin is collected, an Altitude contract is created on top of the Depth, which automatically selects the Crown, or leader content, while incorporating the Candidate. The new Altitude is stacked alternately on both sides of the two collocated darts as it grows upward, automatically selecting the leader content, or Crown, while incorporating the Candidate. When all are in place, they look like blocks of Jenga.

The KickerCoin sets the minimum Coin limit to make the game fair by increasing or decreasing itself according to the total amount of Coins paid by the previous candidate.

In particular, the maximum number of participants limit is calculated from this previous KickerCoin amount. Indirectly control the number of UTs that opponents gain. The coordinator can choose who will be the crown and in exchange for the KickerCoin he has, the crown can pocket the amount of Coins paid when his candidate, but must disappear from the stage (i.e. Altitude Contract) the moment he receives it The other party's wallet must be removed.

KickerCoin is generated primarily by all contributors.

Coins act like water and air in an ecosystem. All species bring Coins to produce an organic compound called UprightToken; KickerCoin is like a pumice stone that regulates the watershed.

The KickerCoin on the code is not a coin, but simply a data field. It keeps the game fair and serves to tie up the feet of coordinators who have not yet produced their input keys.

UT is the ratio of the attractiveness and strangeness (as rated by others) of a candidate divided by the number of people. Its calculation method is

UprightToken (UT) = Number of people in (own block + next block) * Integrity Index

If both indexes are better than the other, the winning side is determined.

(5) Monolithic: After the decision is made, the Altitude enters a state called "monolithic" and all fields in the target Altitude cannot be changed.

The dominance of each Altitude at the same root Depth is determined by their respective "diversity indices" in the community ecology.

・Refunds will be made in Green.

The winner is transformed into a new object with Cartesian coordinates, called a gPole. The leader elected by the group will serve as one of the apexes of the new area (gPole) as the pole position. Then, several other gPoles are also gathered together to form a single polygon called "green".

Eventually, all the dart on the winner's side is released into this polygon.

The characteristic feature of GREEN is that all the contents of the unstable, inside dart will be "released" to the outside world. In other words, anyone can see it. The conditions under which green is created and depleted are briefly described in usegreenmonitor.tsx.

To maintain Green, the cost for area mining (gas) is constantly required, but the "Peg" personnel, who are content viewers at the time of collision, create the graph for mining, and the actual cost is taken from the Charm that the Candidate brings into Altitude. The actual costs are taken from the Charm that the Candidate brings into Altitude. (gas cost matching)

Mechanisms to avoid ruts within Green are, for example, the implementation of FillAreaGas and the existence of HashTraitor. It is impossible to control Green by pre-muzzling, as these cause side effects that both maintain Green and destabilize it. We eliminate the need for unnecessary back-channeling, and by raising funds and selecting personnel at the same time, we are always able to ensure that the project is accomplished in the right way.

・Organizing so far

(1) Difference between Water and Green

Water is characterized by its panels. Each panel has a storage called memory, which stores the PathData of the internal dart. In contrast, Green should be focused on the pole (vertex) rather than the panel. This pole is called gPole and is created on top of the Altitude array. It is created mainly immediately after the leader election ends at the target root Depth. The coordinates are the same from the root Depth to the Altitude array above it and the gPole above it.

(2) Difference in roles of Depth and Altitude

Depth and Altitude are generated at the time of dirt collision and leader election, respectively, i.e., when RubberCoin is minted as KickerCoin. After the leader is elected, all Charms held by the losing side's dart are sent to Depth. This will later be used to compensate for the Charm consumed in area mining. In contrast, a portion of the Charm held by the winning side's dirt is sent to gPole. From there, it is applied in the order of Green generation=>fillAreaGas=>traitHash to compensate for the Charm consumed in the operation of Green, as appropriate.

(3) Difference between Peg and Candidate

Peg and Candidate are essentially the same dirt object that links to multiple objects in the water. What separates the two is whether or not the leader election is initiated. Once initiated, the Peg becomes a Candidate in its original composition (targeting=>targeted). In other words, when a Peg is inserted, it is a potential Candidate. In the case of Peg, you can perform area mining in addition to posting a link, but the result will not affect the Crown election in Candidate.

(4) Difference between RubberCoin and KickerCoin

Simply put, RubberCoin is a Strange token and KickerCoin is a Charm token, and once a certain number of RubberCoin are accumulated, KickerCoin can be generated by swapping RubberCoin, or Strange tokens, for Charm tokens in the belongingWater pool. KickerCoin is generated by swapping RubberCoin, or Strange tokens, with Charm tokens in the belongingWater pool.

・advantages and originality not found in other apps.

GoDaddy is no longer needed in the Web3 world. In terms of setting area accounts, this app is controlled by a proprietary data store algorithm, "area mining," rather than the early birds.

This means that the area data is stored in the blockchain and redistributed to a centralized database repeatedly, thereby creating self-governance on its own platform. Like Ostrom's Commons.

The app is neither a gamble nor an investment, so once you set a Charm value of dart coins, you will never get them back. What is actually consumed when you coin in for self-awareness is a "charge for community contribution" throughout the app.

・Functions and their significance for the purpose

Dart characterization by 6 parameters

Classified into Intentional Parameters (Up, Charm, Top) and Dependent Parameters (Down, Strange, Bottom)

(1) Up and Down

There is no concept of "time" throughout the entire application. Instead, "epoch" exists. Therefore, by adjusting the Charm value by yourself, you can make the time go faster or slower.

(2) Charm and Strange

Charm is the name of the token used throughout the application, while Strange is an indicator used to measure whether the self-assessment is appropriate from the perspective of others. It is also called "others' evaluation. Of course, you cannot set and manipulate this by yourself either.

(3)Top and Bottom

First of all, both are defined as a point in three dimensions where value is z and xy is a coordinate in real space. Top is the position coordinate of Crown, and value, which is z, is the total number of Charm values brought by the Candidate at its internal Altitude.

Bottom is the coordinate of the best Peg, i.e., the dirt that stored the most efficient path data among the Pegs that actually performed area mining. z, the value, is the Charm value stored in Depth that the graph expected to perform area mining will consume in the future.

Therefore, by comparing Top and Bottom, the potential balance surrounding the dirt can be measured.

・About NFT Coordinates

There is a difference between NFT and monolithic NFT. Both of them store coordinates, but the coordinates are respectively an intention parameter for NFT and a dependent parameter for monolithic NFT. In other words, NFTs can choose where to mint at will, but monolithic NFTs cannot decide where the mint is generated.

・The "dogmatic" chain

Candidates for leadership are not determined by the number of votes received, but by the sole discretion of the individual. After a candidate is selected, the diversity index of similar groups within each pole position is compared, and if the candidate clears the rules, he or she is officially approved as a leader. In this case, the number of votes received is only one of the parameters used to calculate the diversity index. Incidentally, the diversity index is calculated not only for a group or an entire area, but also for individual users (intrapersonal diversity).

Newly elected leaders are given the right to have their votes (coins earned) refunded, but this right has a trade-off with the right to retain the right to arbitrarily select the next leader candidate to succeed them from the group. In other words, this right is always instantaneous, and if exercised, the winner immediately loses his/her pole position (selector) in exchange for the coins.

The diversity index is calculated from each dirt's path data, hash-chart (potential balance), various Geo tags, and Peg (Candidate) participation direction, so that the effort spent on vote-buying and back-stabbing can be invested in their own creativity.

Each leader is also responsible for the role of gPole, which defines an area, but the target of selection is not necessarily a person (performer), since it depends on the content of the dirt gathered in the target Geo tag, but also on the tools, schedule, and methods used.

Within an area, the darts gathered in a Geo tag are grouped together, and after a binary structure is established in the initial conflict dart (i.e., the first two darts), they are made publicly available, along with the required total coin amount.

The leader selection module is characterized by open, democratic, and short-term trading, in contrast to the hierarchy of darts in previous collisions (or spread tournaments when darts are congested), and the total coin amount is visualized as growing upward. Also, unlike in the past, anyone can participate, not just members.

In this trial, voting and voting rights are on a spectrum in a single dart, and the dart thrown from outside the area also functions as a vote. Also, no data (i.e., person, coin, or vote) can be referenced from within the area (i.e., the area region where the route Depth or Altitude is located).

By setting coordinates in real space when issuing tokens containing NFTs, it is possible to distribute appropriate salaries to creators by defining a superiority relationship between "extremely subjective content" based on the content diversity index, without collecting personal information. Loose restrictions on the mutual throwing of location information will also stop data leakage, avoiding round-about discussions and ensuring diversity in the organization.

・Money (Charm) or Authority (Strange)?

In this game, you do not get your coins back whether you win or lose. This is because it is neither an investment nor a gamble. Instead, you can publish content within the community, which will be used to maintain the area.

While the same dart is allowed to belong to two locations (i.e., Targeting and Targeted), this specification serves as a tool to expand or contract the area according to the organization's wishes. If you want to make an area larger, you can invest as many coins as possible and set up the dart affiliation as broadly or decentrally as possible. On the other hand, if you want to reduce the size of the area, you can do so by concentrating on a limited number of affiliations.

If the goal is to achieve stable operation of the organization, it is necessary to increase the diversity index within the organization, and for this purpose, the area of the area should be increased. However, the larger the area, the more information that cannot be referred to, and this is not good for seizing authority, since there are necessarily fewer options for sending out leaders from within the organization.

On the other hand, the characteristics and advantages of a small area are that it can be operated with a small amount of coin and there is little risk of authority being taken over by others within the area, which means that "transaction costs" within the organization can be reduced. The disadvantage is that the amount of coins that may be obtained is necessarily lower. In addition, the diversity within an area tends to be low, which can easily encourage the emergence of hash-traders, making area instability inevitable.

・The Role of Area Mining

The significance of area mining is mainly the decentralized management of the Water area, i.e., the gimmick to escape censorship, but it is not the only one. Mining allows you to receive Strange tokens as compensation in exchange for consuming Charm yourself. In other words, even if your content has no appeal, you can collect pieces of authority (Strange) as long as you pay money (Charm tokens). You can be elected as a coordinator according to the amount of Charm you hold. In a sense, it is a system that allows you to buy authority (in short, talent) through a democratic process.

・Three ways to fight off crackers

1. The $1 Big-Name Problem: High-profile individuals offering fewer coins.
2. Got's Talent Problem: Low-skilled amateurs with big capital background.
3. Byzantine Art General Problem: 51% attack by performers.

(1) This is easy to deal with: the reputation of others rises without exception according to their ability and fame, so if more than a majority, or $2, is bought by others, the token (the right to a refund) is quickly taken away. This is not an infinite increase if there is more than one. From this simulation, you can understand that this is not realistic. Due to the lack of diversity in the index, the crown would be quickly taken away by the "one dollar pirate".

(2) There is nothing wrong with putting up a big coin. However, if the content is severely dissociated from the valuation of others, i.e., valued too cheaply, the ownership of the content itself may be lost. The content may also be removed as not being used. If there is more than one candidate, the total coin limit, which is a weak point in the candidate determination process, may be reached quickly and the number of candidates may not increase. Even if they are selected, the coordinator will take the maximum amount of Coins. The simplest way to deal with these problems is to continue to act honestly, pay self-assessment Coins with self-awareness, follow one's heart, and correctly measure the value of one's content.

(3) General Problems of Byzantine Art

There are not many situations in which multiple people in the same position have to make decisions at a distance. Unlike in the beginning, which was established by a chain of individual decisions, only monolithic content is owned by multiple Crowns. The next new decision must have the consensus of an equal number of crowns.

The method used there is again a pecking order among crowns using the diversity index.

It is not easy to profit from a continuous 51% attack by performers because of the Blooded system. The diversity index must be constantly raised, because if the diversity index between groups is lower than the other groups, their crowns will be stolen (i.e., their authority will be stolen). This would be as unfeasible as forever increasing the supply of coins in the game.

Green generation integrates dogmatic towers by persons of different backgrounds in a completely separate environment; even a 51% conspiracy must be dammed up because there is no systemic mechanism. Dogmatism will foster another dogmatism. Our policy is to protect us from the danger of being attacked by accelerating and expanding dogma. Nevertheless, sometimes a one-time dogma can produce good things. So, to prevent that from happening on an ongoing basis, we have our own "minting policy".

Our system believes that large holders should always be encouraged to take big risks, work to maximize their overall non-monetary profits, and toss coins to another talented person. They must take the risk of creating a larger KickerCoin. If they take less risk themselves, the policy will be to mint more new coins. Ultimately, increasing the overall number of holders and their spread will solve this problem.

・Future development of this application

Currently, it consists of borrowing URLs from famous sites such as YouTube and SoundClound, but in the future we will consider outsourcing the store of these contents to a decentralized file system such as ipfs.

As for the algorithm of the diversity index, it is a problem that does not have an answer like the algorithm of a search engine, so the specification will be changed in the future.

・Plug-ins as in-app applications

What specific content will be combined? We will also consider what we aim to achieve by combining them.

What kind of plug-ins are we currently considering? chiKem: This is an automatic video editing application for live concerts. Total Cassette: A ticket to the theater that can audition and attract audiences at the same time. SadStoryCoin: Create a chain that always covers the tragedy. A chain of interlocking dogmas.

But these plug-ins should be done by setting up their own coins.

・Other Use Cases

In addition to internal project management, the system can also be used as a general public facility management tool. For example, it can be used as a community association management tool for community residents, as a tool to assist in the management of music festivals, and in other cases where fees must be collected directly from customers, such as in the commercial, entertainment, tourism, and business areas of redevelopment projects in cities in developed countries in recent years. The use of the system is particularly effective in areas where the boundary between private and public interests is blurred, such as commercial, entertainment, tourism, and business areas, as seen in redevelopment projects in developed countries.

・Conclusion

We present a decentralized platform for publishing content anonymously without trusting a malicious central authority, and the mechanism itself induces unprecedented connections between products. Decentralized recipes are beneficial to those who are keen to collect content on an ongoing basis, since a clear consensus of rewards is factored in. There is no need to fear unauthorized or modified use or advertiser "baiting censorship"; selecting new content in the Stitching Algorithm can be pre-funded and easily localized or expanded depending on demand and number of participants. Such a great incentive is an essential requirement for all unborn intangibles.

This Oddlung encourages all users to dive into paid services and escape from the slavery of freemium.

・Why did I apply for the UNI Swap?

To sum up, because Oddlung is a DEX itself. By using this application Oddlung, you may enjoy other people's content and meet people you don't know, but that is just a side effect in the autonomy of Green (i.e., commons), as this application calls it.

In addition to the conflict-driven mechanism with the three types of crackers, this app has so many specific "motions". In addition to the three types of conflict-driven mechanisms, the app has many specific "motions," ranging from collision of dirt to content evaluation, Candidate recruitment and deadlines, Crown selection and nextCoordinator selection, and so on. This is an application specification where the Hooks implementation that appeared in UniswapV4 can be used.

After investigating various partner technologies, I realized that most of the functions in the application can be implemented with the three operations of Swap, LP (add/delete), and donation in UniswapV4. For example, among the objects, Dart, Water, and Green can be regarded as liquidity pools, respectively.

This has led us to realize the limitations (mainly in terms of security) of managing the parameters (token ratios, etc.) of each dart off-chain by holding Charm tokens, etc. at a single address (meta mask, etc.) when a single user holds multiple darts. This time, treating the objects in the application as a liquidity pool may resolve those concerns. Of course, there would be gas consumption and various other inefficiencies that would result from multiple LPs and swaps, but we felt that replacing some of the functions in the app with Uniswap would not be a waste of time.

Therefore, we categorized the Uniswap methods from the app's operations and functions as follows.

(1) Those that are Swap are used to pass tokens to other pools. (Swap in your pool => swap in the other pool)

(2) Those that are LP are used to temporarily add tokens to the other pool. (delete=>add double LP)

(3) Those that are donations are used to forfeit tokens.

Therefore, from this point on, we decided to define new Hooks methods in the form of additions to the existing hardhat/contracts contracts, focusing especially on the areas where the swap, LP, and donation functions can be applied.

・Uniswap-v4 contract description

1. Charm.sol

This is a basic ERC20 contract. mint function can be created by yourself.

(2) Strange.sol

This is the same ERC20 contract, but there is a rule that you cannot mint it by yourself. The price of the Charm token fluctuates depending on the increase or decrease of this Strange token in the Dart pool.

(3) DartPool.sol

A contract as an interface that governs user operations. When a Dart pool is created and the desired Charm value is set inside it, the Strange token of the same amount will be minted at the same time.

In addition to Charm and Strange, an ERC721 token is held for ownership of the content he holds. This should probably be defined in ERC1155, but for the sake of posterity, we will create it as a normal contract.

The actions that DartPool can perform are mainly the creation of pegs and area mining for the contents of darts that belong to other water pools.

Basically, a DartPool cannot exist on its own, but can always be associated with a belonging WaterPool.

Peg creation links targeted (i.e., the creator's dart) to targeted (i.e., the content owner's dart) and transfers Strange in both dart pools from Targeting to Targeted, while Peg creation, or content In browsing, the Strange transfer is temporary, while the Strange obtained in mining is permanent.

In addition, a function was added as IDartPool.sol to virtually transport tokens from pool to pool by performing the swap and LP defined in DartPool.sol twice.

(3) WaterPool.sol

This is a fluid pool with an array of coordinates corresponding to the real world. Strange tokens in the dirt pool are not included in the token holdings in this Water, and the only tokens that are put in at this location are Charm, mainly at the time of dirt creation and at the time of Charm donation by Root Depth after failure to create the first Altitude after KC creation The two types of tokens are.

(4) GreenPool.sol

What occurs in the process of Green Autonomy is LP and donation in addition to swap, and this is undoubtedly the most delicious part from the Uniswap point of view, but in this place, mainly individual Dart (i.e. Dart Pool) double swap with Water and Green Pool to remit Only methods are presented. This is because most of the swap logic is implemented off-chain, and it is time consuming to extract that element.

Within Green, Charm tokens held by the winning side in the leader election are released.

The Charm tokens held by the winning Altitude array are temporarily stored in gPole, which is created on top of the Charm tokens.

If the diversity index of Altitude or gPole is low for Dart here, Dart may be at a disadvantage in the swap.

(5) Depth.sol

Contrary to Green, the loser's Charm is sent to the root Depth and becomes a Depth token. The tokens entered here are restricted in use and can only be used to cover the cost of area mining.

This is the reward (which is an opportunity, not money) if the subject of the Depth token acquirer is a minor. And from the perspective of the Depth contract, the value of the bottom.value is the total amount of those combined.

The KickerCoin mechanism needs to be expanded; KC was just a data field, but UniswapV4 on UniswapV4, we will treat it as an ERC20 token with a lock function that contains metadata.

This means that the RubberCoin mechanism needs to be deployed. This is a throwaway coin to some extent. The KC would be set equal to this total amount. In a dirt collision, a certain amount of Strange is accumulated, and under certain conditions, the RubberCoin (i.e., temporary Strange deposit) is used to swap real Charm tokens from this location (i.e., Water) (normal).

(6) Altitude.sol

This one also has restrictions on the use of the tokens entered; they can only be used for pooling money for the generation of Green. Each Altitude created above the rootDepth has its own wallet, but the looseness of that wallet, i.e., the ease with which it can be taken by another Altitude or gPole, becomes looser the smaller the UT value.

・Detailed explanation of other codes in the project

(1) Explanation of each Solidity contract

The Solidity contract codes are all limited to basic implementations. The following is a brief description of each contract.

Altitude.sol // A contract generated when the Depth object is set to start leader election under certain conditions.

Coin.sol // An ERC20 contract for minting and transferring Charm, the proprietary token in the app.

Content.sol // ERC721 token contract for proving possession of content on Dart.

Dart.sol // Dart body contract including the ability to transfer Charm tokens to Altitude; Signer is user owned.

Depth.sol // A contraption that is automatically generated when Dart collides with other Dart tokens. This contract stores the results of area mining using an empty graph in the off-chain depth object.

Monolithic.sol // Contract for minting monolithic NFTs after leader election is completed.

(2) Detailed description of each file in Next.js (TypeScript)

Code groups for algorithms on the map

useGreenMonitor.tsx // custom hooks for generating and updating Green

useFillAreaGas.tsx // custom hook to check if gPole[] has the total amount of Charm for the Green area to be created.

useHashTraitor.tsx // custom hook to expel the Altitudes in the gPole with the highest Charm total when the Green diversity index falls below a certain number, or to determine this.

・Code group containing Odd logic

UpdateDartsUtils.tsx // Code to UPDATE the dart movements in the area.

VertexPartolUtils.tsx // Logic to find the corner of the Water area.

VoidExplorerUtils.tsx // Detailed mining scoring method is still to be written.

・Code groups containing parameter calculations

DiversityIndexUtils.tsx // As the name implies, various codes to calculate the diversity index

BloodedUtils.tsx // This is the code for determining when a Crown steals a Crown, i.e., to kick it out. It uses the diversity index calculation function internally.

AffinityUtils.tsx // This is code for calculating Affinity, which indicates the connection between gPoles

(3) Contents and intent of each component

AreaWindow // displays a world map or polygons of individual areas

ContentDefaultWindow // introductory page for popular, newest, and oldest content

ContentWindow // Displays thumbnails of content cropped into puzzle pieces. Peg=>Candidate=>Crowning=>Kicking=>Monoltihc

CreateWindow // Page for creating a new Water

DefaultWindow // Introduction screen

DepthDefaultWindow // Displays the ranking of the total Charm amount and the ranking of the Water depth

DepthWindow // Displays the internal status of the Water, mainly in terms of depth. Also allows viewing of individual dirt paths.

GlobalNotification // This is not yet implemented, but it delivers notifications to specific users (listen for contract events in ethers.js)

Header // Header

LeaderDefaultWindow // displays the heated Altitude and Green in a ranking format

LeaderWindow // This location displays the time limit, various Indexes, and Altitude status

ServerDownPage // As the name suggests

SettingWindow // This is currently under construction

SidePanel // Side panel

TxList // List to be trimmed for each event; will use etherscan

(4) About the data model

altitude.ts // Data model for Altitude object.

content.ts // Data model for content containing NFT.

dart.ts // Data model for Dart objects.

depth.ts // Data model for Depth objects.

geometry.ts // Data model for definitions needed for computational geometry.

green.ts // Data model for Green related data model.

ledger.ts // Data model for various rankings.

monolithic.ts // Data model for monolithic NFT (deprecated)

taskAndRole.ts // Data model for in-application apps.

txevent.ts // Data model for various event generation.

water.ts // Data model for Water object.

(5) Other files

contexts/. This was written in the form of a quote from the educational sample code for creating DEX on Udemy. It has been approved by the creator.

・technical difficulties

When there are too many darts within a particular WATER, or when the WATER area is too small relative to the number of darts. The mechanism is based on the concern that if there are too many darts in a particular pool, which are squeezed together like a crowded train in Japan, the number of collisions will be too high, and the system will be distracted from its original purpose. In other words, the class_value is incremented as if the dart of the winner of the collision, i.e., the side with more Peg links, would dive down one level.

Since only darts with the same class_value are eligible for collision, the number of opportunities is considerably reduced. If the number of darts is reduced, it may conversely return to the original class_value.

The implementation of the class_value mechanism should automatically adjust the amount of data (in this case, the number of darts in an area), as in the 10 minutes before the creation of a bitcoin block. Verifying its mathematical validity is the difficult problem.

The next difficult question is about the multi-threaded synchronization of the dart process in the UpdateDartsUtils.tsx section. How can we reduce the gas cost of storing Path data in Solidity? Also, how to connect the time series when browsing the data. Due to time constraints, the store of Path data to ipfs has not yet been implemented. Instead, three hashes (store label, internal index, and external reference) are stored in Depth.sol.

・My failures, aha experiences, and future hacks

The main reason for the lack of data in the app is the stalled implementation in UpdateDartsUtils.tsx as I did above. The main reason why it was so fiddly is that we were too focused on animated expressions.

The closest meaning of "fire fool power" (I don't know if such an idiom exists in English-speaking countries), would be something like "runner's high". Aha effect.

I want to give you an image. If you were to play billiards in zero gravity, you would know the position coordinates of the ball 100 years from the moment you hit it with the cue. This is of course a fictitious experiment, but assuming that the ball maintains its initial motion without any friction and without any loss of velocity, such an observation would be expected.

When I applied this to this application, I realized that what I was trying to achieve was neither high nor low difficulty.

So here's what I'm trying to do. If I generate a series of PathData that first obtains the expected collision coordinates for each of the upPanel and downPanel, and keep the generated coordinates and current speed separately, I can always predict the future of that dart. The only time this becomes useless is when the owner of that dirt replenishes (fillThePump) the Charm in its dirt pool, but even then, you can simply generatePathData() again.

Both my PathData and others' PathData should be collected in the center of each area in a single step, and it would be a good idea to save each of them in Dart's contraption as well, just in case, so that they can be backed up.

I said at the beginning that Dart is a UTXO, but on the contrary, this bundle of PathData is a blockchain of Swap transactions in the future.

With this, anytime someone else generates additional dirt in Water, it is simply a matter of adding more to that central PathData each time. Of course, the list of predicted collisions would have to be updated each time, but the data would only be coordinate data, which is not much more trouble than the real-time monitoring on the server side described earlier. In addition, since the data to be referenced in this method can be referenced as static data from the UI component, it is possible to obtain the current coordinates and direction of travel of one's own or another person's dirt from the current time, making it very easy to create animation expressions. Naturally, it is also easy to update the predicted collision between dirts based on multiple PathData, in real time.

Animated expressions are not necessary to begin with. It is simply for debugging. There is no need to represent moving dirt at all, because the basic principle of this application is that only stationary dirt is visualized. What I misunderstood was that during the hackathon I was trying to represent all dirt trajectories in all areas on the server side in real time.

This realization is the biggest achievement of this project. Well, to put a finer point on it, the list of collision forecasts should be updated faster than humans can keep up, or only accessible by multisig. It should be encrypted, etc. If the list of collision estimates calculated from a bundle of PathData is stolen, the future transactions will be stolen. This is important to prevent the thief from becoming a billionaire like Biff Tannen in Back to the Future 2.

・Future Prospects

I am probably the only OpenLayers library user of all applicants. In fact, most of the powerful bugs in application production were minted from this library. Hey guys, welcome to the GIS Summit 2023.

While many of the entrants have (pre-)implemented minimalistic prize friendly apps, I ran out of time because I was trying to create a full sized web app. Video was abandoned because my M1 Pro iMovie were too slow.

Overall, I tried to avoid hacky, pedantic implementations and stick to the basics. I emphasized conveying ideas and inspiration rather than actual movement. However, we avoided implementation with extremely low feasibility. Since time was extremely limited for this project, we focused on the map function to clearly convey the concept of the application, and simplified the UI and avoided implementing details.

As for content support, only Youtube is supported (SoundClould api was not available), but we intend to expand the supported content in the future.

In addition, the off-chain data model was created by Mongo and mongoose to support on-chain, but this may be simplified in the future after we confirm Solidity's behavior.

I would like to inform the judges that I now know perfectly well what I need to do now regarding this application. All that is missing is time.

Libraries used

Next.js

Mongo DB + Mongoose

hardhat

ethers.js

OpenLayers

Ant Design

Uniswap-v4 Hooks