I have a proposal that enhances UIA in a small way but provides the foundations necessary to implement really powerful things. This includes things like hierarchical DACs all sharing basically the same BitAssets (the ones minted into existence in the root BitShares DAC), side DACs that implement new experimental features that we don't (yet) want to implement on the main DAC and that we rather not implement with less efficient Turing complete scripts, and other possibilities.
A UIA would have a unique ID and it would at a minimum define a delay period N (in blocks), a consensus threshold C (as a percentage between 0% and 100%), a panic threshold P (as a percentage between 0% and C%), a false panic tax T (as a percentage between 0% and 100%), and a manager. The manager could be a single address but would generally be a multisig address. The UIA would also have a reserve associated with it. You can think of this reserve as a vault that can store any digital asset in the DAC that can be owned by users/addresses, and while anyone can deposit these digital assets into the reserve, only the manager can withdraw it.
Transactions dealing with UIAs would be in one of two classes: instant transactions and delayed transactions. Instant transactions would be transactions which have effects that immediately occur in the blockchain. Instant transactions include: depositing digital assets into the reserve; moving any UIAs that exist outside the reserve; changing the votes associated with UIAs that exist outside the reserve. Delayed transactions would be transactions that only go into effect after N blocks have passed since the transaction was first submitted into the blockchain unless a panic was initiated. Only the manager is allowed to submit a delayed transaction. If a panic is initiated, any delayed transactions that have yet to become active are put on hold. If the panic is lifted as a false alarm, the hold is removed and the delayed transactions can become activated if N blocks have passed since they were first submitted to the blockchain. If the panic is ratified, all of the delayed transactions that were put on hold become void. Furthermore, while a panic is in effect, no delayed transactions can be submitted to the blockchain. Delayed transactions include: changing the variables N, C, P, T, or even the manager of the UIA; withdrawing digital assets from the reserve; issuing a certain amount of new UIAs into existence that automatically go into the reserve.
A panic for a UIA can be initiated if enough UIAs vote in favor of initiating the panic. If the percentage of UIA supply existing outside the reserve that are voting in favor of initiating the panic grows above the panic threshold P%, the panic is initiated and a T% fraction of all of the UIAs that voted to initiate the panic is taken by the DAC and locked in escrow. The original owners of the UIAs from which that T% fraction was taken are allowed to change the votes associated with those UIAs locked in escrow but they are not allowed to move the funds to new owners. If the panic turns out to be a false alarm, the UIAs taxed and put in the escrow will automatically be moved into the reserve and the original owners will lose full control of those UIAs. Otherwise, if the panic turns out to be legitimate, the UIAs held in escrow will be returned back to their original owners so that they can have full control over them. The DAC decides whether an initiated panic was a false alarm or legitimate by the way UIAs vote during the state of panic. If more than C% of the UIA supply existing outside the reserve vote that the panic is a false alarm, then the panic is lifted and treated like a false alarm. For the panic to be treated as legitimate however, it requires more than C% of the UIA supply existing outside the reserve to agree that not only is the panic legitimate but also agree on a new manager to replace the current manager. Once this greater than C% of UIAs are voting in favor of treating the panic as legitimate and
voting for a new manager M, the panic is lifted, the taxed UIAs in escrow are sent into the reserve, the delayed transaction on hold are made void, and the old manager of the UIA is replaced with manager M.
So those are the mechanics. What possibilities do these mechanics allow for? Well consider the case where the manager is a 51-of-101 multisig. This allows for a side DPOS-like DAC to be created that is tied to the main DAC. Everyone validating the side DAC will also be validating the main DAC. The side DAC can have whatever business logic it wants. And its consensus logic will be similar to DPOS but also different in significant ways. First, the block producers can just be the manager. A block can not be considered valid unless it has 51 of the 101 signatures as defined in the manager for the UIA on the main DAC. The 101 keys of the manager could be the 101 delegates of the side DAC. The delegates can communicate on their own private network to come to a consensus on the state of the next block (which can simply be done by sharing with each other the block hash of the block they are each individually building anyway) and then they can all (or at least 51 of them) sign that block and share the signature with each other so that it is an official block that they can broadcast to the network in time. Although the UIAs are owned on the main DAC, the child DAC can track the votes that are being modified on the child DAC's blockchain under the authority of the UIAs on the main DAC's blockchain (verifying that the public keys match). This allows the child DAC to come to a consensus on who should
be the new 101 delegates as soon as possible using whatever voting system they want. It doesn't become official for the child DAC however until the change is made on the main DAC. This means that the manager of the UIA on the main DAC needs to submit an instant transaction changing the manager to reflect the delegate changes on the child DAC. If the manager does not do this within a sufficient period of time, the owners of the child DAC (the UIA holders) will initiate a panic and replace the managers through a vote with greater than C% consensus. This means that the mechanism I described in the paragraphs above allows the delegates of a child DAC to be gradually changed like in DPOS, but it has some other benefits. First, if the delegates of the child DAC are compromised a hard fork is not necessary because the tools to replace the delegates already exists in the main DAC. The stakeholders of the child DAC can easily come to a consensus on which new delegates replace the old malicious delegates. Second, since these child DAC delegates are also synchronized to be the manager on the main DAC, it allows these delegates to effectively move digital assets between the main DAC and child DAC (this is somewhat similar to side chains). A digital asset can be deposited by a user into the UIA's reserve. The delegates (and all other validators) can monitor this on the main DAC and mint a digital asset derivative on the child DAC which is credited to that user (same public keys). The opposite direction can also be done by destroying the digital asset derivative on the child DAC and withdrawing the digital asset from the reserve to deserving user, but this step has the N block delay for security reasons. This means that users can use a BitUSD derivative on a child DAC which ties its value back to an actual BitUSD held in the reserves on the main DAC which ultimately ties its value to BTS. As long as there are enough (P% of UIA) honest users actively monitoring the two chains to make sure the manager/delegates behave according to the rules of the child DAC, then users who deposited their BitAssets into the child DAC can be confident that their BitAssets won't be stolen from them. If the manager breaks the rules, the P% of UIA will vote to initiate the panic and put a hold on any offending delayed transactions. The UIA holders are motivated to do this (and put T% of their funds at risk) for legitimate panics, because after the panic has ended they will be rewarded with a certain amount according to the social consensus of the child DAC. The reward could come from some amount of the BitUSD held in the UIA's reserve which is allocated for this purpose and paid for by some percentage of the transaction fees on the child DAC. Then, after the panic is initiated, since the users (and UIA holders) of the system will be motivated to resolve the panic and return things back to normal operation, users can be confident that if the panic is legitimate then more than C% of UIAs (ignoring >C% stake attacks of course) will vote to replace the evil manager with a new one and end the panic.
The framework I described above can be used to launch a new experimental DAC with some new features. This can be done without affecting the operation of the main DAC or any of the other existing side DACs. Perhaps we want to test some new market features like a bond market. Perhaps we want try out features like dominant assurance contracts or smart loans collateralized by digital assets. Sure a lot of this could be done using Turing complete scripting, but I worry that this can add a lot of load to the validation of the main DAC. I worry about delegates (and even all full nodes) being forced to run through potentially very long scripts (even though there could be enough "gas" to pay for it) just so they can properly validate that the previous block that they are building off of is legitimate. I'm concerned about the synchronous nature of the scripts/contracts in Ethereum and most likely eventually BitShares as well. But with the child DACs, only the people who actually care about what that DAC is doing need to use resources to validate their blockchain. To everyone else it appears as if users are depositing funds in the UIA's reserve and the UIA manager is withdrawing funds from the reserve and sending them to some users. The outsiders do not need to understand the complicated logic behind those digital asset movements, unless they want to, in which case they are free to download that child DAC's blockchain and validate the custom business logic of the child DAC. The child DACs can also communicate via the manager with other child DACs. In this case the receiving child DAC needs to validate the chain of the sending child DAC to make sure the manager has the authority to send the message. An alternative mechanism would be that the manager uses a delayed transaction to broadcast the hash of a message directed to a particular child DAC on the main DAC's blockchain. The receiving DAC would need to receive the actual contents of that message on their network but off the main chain (likely received from the manager/delegates of the sending DAC) and would only consider the message valid once the delayed transaction went through after the N blocks without becoming void due to a panic. This would allow the block validators of the receiving DAC to just process the message without needing to validate the sending DAC's chain to determine whether it had the authority to send that message. With interchain communication and fund transfers, many things become possible. It is possible to have each of these child DACs house the different functionality powering autonomous software agents and let the software agents communicate with each other and send money back and forth. Ultimately the UIA holders of the child DAC are responsible to make sure the software agents are operating (operated by the manager/delegates of course) according to their published source code. The UIA holders would bother to do this check because ultimately they are the ones receiving the profits from the service of running the software agents (after paying the manager/delegates who are employed to actually run the infrastructure), and the only way they can continue to make a profit is if they continue to receive the revenue paid for by the transaction fees / gas paid by the users who are motivated to have these software agents operating. Also, the framework I have described gives a lot of flexibility in how these software agents / smart contracts can be implemented. The way the gas is calculated can vary from DAC to DAC (or even within a DAC) depending on the business model the DAC wants to focus on. The language or even VM that must be used to implement these smart contracts can also vary between DACs.
Finally, this framework allows for the DAC to scale without reducing the demand for BTS in the root DAC. You can think of each child DAC as a separate bank (perhaps even specializing in particular exchange markets) which has BitAsset derivatives as liabilities to its depositors and the actual BitAssets as its assets held in the reserve on the parent DAC (think of member banks holding USD reserves in the central bank, like the Fed, except with 100% reserve). These BitAsset derivatives are 1-to-1 pegged to the real BitAssets held in the reserve of the parent DAC. The child DACs can even hold some excess BitAsset reserves (collectively owned by the UIA stakeholders of the child DAC) to allow rapid transfers of the BitAsset derivatives between DACs while never going below a 100% reserve. By regularly settling between the DACs using the delayed withdraw transaction, they can maintain enough excess reserve to allow fast inter-DAC transfers even as the reserves from one DAC-bank are slowly drained over time and moved into another DAC-bank. So from the user's perspective it would typically appear as if they can transfer funds both within a DAC-bank and between DAC-banks instantly. Of course in the worst case scenario, the withdrawing users would only have to wait N blocks (which I think can safely be as small as 8640, or 24 hours with 10 second block times) to withdraw any amount out of the DAC bank. Also, for maximum scalability, child DACs can have their own child DACs using the same mechanism (in this case the grandchild DAC's UIA stake would be held in the child DAC, and the child DAC's UIA stake would be held in the root DAC). There is no reason the depth of the tree has to be limited to 2. By allowing arbitrarily deep DAC trees, the number of DACs using essentially the same BitAssets can scale to a large number L while making the worse case time to move funds between DACS to be approximately (Nbar + 1) * (10 seconds) * log(L), where Nbar is the average value of N for the DACs along the upward branch of the tree, and making the worst case number of transactions (and thus transaction fees) to be proportional to log(L). Of course in that case it would probably make more sense to save time by just paying a liquidity provider a small fee to do an atomic cross-chain trade of the sender's BitAsset derivative on the from-chain with the liquidity provider's BitAsset derivative on the to-chain.