译文/Translated：
Ƒractally是建立在EOS上的吗？
Ƒractally是建立在真正的民主和社区独立这两大价值观上的。我们想集成所有的区块链社区，因为每个人都能从互通的Respect代币（Mutual ℝespect）中获益。我们认为，fractally运行的平台应该重视分形治理和真正的民主。EOS有机会转移到分形治理中，但前提是EOS网络基金会和超级节点要有志于此，它们必须承诺把EOS每年通胀的2%用以补贴分形治理团队的ℝespect代币，同时，21个超级节点中应该有11个由这个团队委派。
这样就能保证EOS网络存在充分去中心化的治理系统，权衡真正的民主和基于代币权重的观点。这是EOS成为DAO（分布式自治组织）领袖必要的一步。fractally希望能看到EOS成为无数fractally成员的家园。
Eden on EOS的未来是什么样的？
Eden社区是第一代的分形治理社区，它也获得了EOS网络基金会的资助。4月9号，它们会进行下一次选举，fractally承办选举过程。
fractally白皮书是我们提出的章程，它会给Eden带来新的活力和问责体系。如果Eden社区同意该章程，它们就可以在4月9日选择一套新的首席代表，这些人可以批准相应资金，让Eden彻底转型成完全分形治理的社区。
fractally怎么利用Mandel?
fractally正在开发一整套下一代的DeFi（去中心化金融）标准，包括代币标准、NFT标准、高质量名称系统、高质量代币代号系统、去中心化交易所。fractally需要制定这些标准、实现愿景。
此外，fractally计划构建更快的确定性、支持同步调用、关键值数据库api。fractally已经向EOS网络基金会提交了一个提案，构建最简可行产品，包括所有新的DeFi标准。这些系统合约需要70万个EOS。此外，我们还需要80万个EOS购买更快的确定性和同步调用。
为什么EOS需要新的代币标准？
现有的EOS代币标准当时是围绕着“require_recipient”范例设计的，其目的是处理储存和提取要求。旧的这个设计让用户能够在转移被发起时停止交易。这样，处理代币的合约就要启动“储存”/“提取”流程。这就在每个交易中创建了“平衡表”。但这就带来了代码膨胀和安全问题。一个简单的数学错误或者黑客行为就可能破坏合约代表用户维护的所有“平衡表” 。
此外，自治DAO有能力在任何时候升级自己的智能合约。这样它们在代币膨胀率方面就不能做长期承诺。新的代币标准让每个人都能创建代币（不管有没有代币代号）。这就要利用一个所有代币共有的通用合约账户。如果DAO能拥有全部控制权（除了超过选定界限的通胀率），它就能收到召回命令，废除代币行为。
新的储存/提取过程不再利用“require_recipient”，因为我们觉得这个功能应该被谴责。它会把现在每个智能合约管理的“贷方”表转移到代币合约中。这样就能保证合约能够发送和获得款项，但不用担心通知处理程序停止交易。
此外，每个代币都会有一个32字节的ID号，也可以选择配对到全局符号表。这就会大幅度减少DeFi应用的RAM需求，最终就能减少开发者成本，并进一步增加EOS作为主要DeFi平台的吸引力。
为什么EOS需要新的NFT标准？
现有的NFT标准关注“艺术”和“藏品”，并不适合人们想在DeFi平台交易的各种非同质化资产。在我们提出的NFT标准中，NFT不过是一个独特的64位数字，其所有权可以利用与新的代币合约相似的API转手。
更高的标准（如AtomicAssets）还是可以被用来促进特殊的NFT资产的创建和交易。理想状态下，所有更高的标准都会升级自己的智能合约，利用我们核心NFT框架，实现更高的安全性和更好的互操作性并减少成本。为了实现这个目的，更合适的方法就是把我们提出的NFT标准作为“标准的标准”。
高质量名称、代号名、账号、代币发行者权限，这4者会率先使用新的NFT系统。任何想要创建可交易的权限组的用户都可以利用这个新系统。
为什么EOS需要新的账户命名系统？
EOS支持的12位名称从来都没打算要面向用户。正相反，它只不过向提供一个和BitShares上相似的执行细节罢了。人们需要把64位的数字当作base32编码进行解读，最后“可以被人类阅读”。
我们建议要把现有的账户名做成执行细节，采用更长的32位名称。此外，我们还建议增加一个新的32位数字，让每个账户可以独特地被识别出来。这样就会减少合约的RAM需求，让数据库连表查询更快捷，因为名称和代币都利用32位数识别。这就能让账户/代币对符合单一的64位指数。
现有的高质量名称拍卖不仅耗时，对用户也不好。我们提议的系统下，名称应该有“马上购买”价，该价格会根据需求实时调整。
你们提出的代币标准是怎么样的？
下面的时序图画的是用户Alice（用32位用户代码表示为u1）购买代码为CAT的代币，然后发行一个新的同质化代币类型，并把CAT作为其代币代码。
直线代表动作或内联动作，框代表智能合约，虚线代表发送到某个没有合约的账户的、不受区块链环境影响的内联动作（即事件）。
这个图表不能反映了“自动扣款”选项，有了这个选项，Alice就没必要单独索取发送给她的代币了。
你会注意到有两个NFT被创建出来，一个是给CAT代码的，另一个是给这个同质化代币的发行者权限的。
下图画了新的NFT标准如何促进任何支持新标准的DeFi应用账户交易。这就意味着账户、发行者权限、代号名称、高质量账户名都可以被作为DeFi抵押物。
新标准会不会影响到现有的代币合约？
我们会准备一个代币转移合约，它会自动、去信任化地让每个用户把现有的、私人合约管理的代币转移到新标准管理下的合约中。用户能够无缝地在新旧合约中转换。
超级节点为什么一定要批准新标准？
我们认为，广泛的社区支持是新标准成功的关键，我们也相信，”eosio.*”开头的账户更可信。新的账户名购买系统会要求对现有的系统合约进行一些升级，避免在新旧两种名称分配的时候产生的歧义问题。这对安全性来说至关重要。
这会需要对/v1/ API及其它API进行升级吗？
/v1/ API永远都是/v1/ API。我们可能会提供新的API，简化接入。但是对这些API的升级并不是我们提议的工作的一部分。
这回需要对合约SDK和客户SDK进行升级吗？
每个想利用新代币的客户都希望能在新SDK中利用新的库。
这会怎么影响现有的钱包吗？
支持新标准就需要所有用户接面能显示新动作、平衡表、以及名称/数字注册码。fractally会提供这种界面的参考实施。现有的钱包和用户界面如果选择不升级，那么只能用在和旧币、符号和名称的交互中。
Eden on EOS是DAO吗？
根据周期性选举的结果，一些EOS会分配给成员，Eden1.0就是维护这些EOS的组织。如果EOS没有按照原定的目标分配，反而丢失了，那么组织就没有预算了。所以，Eden1.0并不是DAO，因为它不是自治的。但如果Eden转型到分形治理，它就会有自己的代币，成为完全自治的DAO。
EOS是DAO吗？
EOS网络有自己透明的账本，也可以在未能达成共识时由社区分叉。EOS利用权益委托证明（DPoS），能为社区观点负责。从Steem上做的Hive分叉就证明了一个基于DPoS的完全去中心化且自治的社区可以解决治理争端。
尽管EOS是自治的，目前的治理结构还是Yves领导的EOS网络基金会中的中心化结构。除了Eden on EOS，预算决定还是用中心化的模式做出的，EOS的普通用户如果不同意决定，他们除了出售EOS以外，也没有什么可行的求助方法。
EOS可以应用完全去中心化的分形治理，把权力还给平台上的用户，去中心化资金决策。
原文/Original：
Is ƒractally building on EOS?
ƒractally is built on the values of true democracy and community independence. We aim to integrate with all blockchain communities because everyone benefits from Mutual ℝespect. We believe that ƒractal’s should operate on a platform that values fractal governance and true democracy. EOS has an opportunity to migrate to ƒractal governance, but it will take a firm commitment of the EOS Network Foundation and Block Producers as demonstrated by a commitment to subsidize a governance ƒractal’s Mutual ℝespect with 2% annual EOS inflation and empower this ƒractal with power to appoint 11 of the 21 block producers.
This will ensure that the EOS network has a sufficiently decentralized governance system that factors in both true democracy and token-weighted opinions. This is a necessary step for EOS to become a DAO of DAOs. ƒractally would love to see EOS be home to countless ƒractals.
What is the future of Eden on EOS?
The Eden community is the first generation of fractal governance and has received funding from the EOS Network Foundation. They will have their next election on April 9th and ƒractally will provide services to host the election process.
The ƒractally white paper represents our proposed bylaws that will bring new energy and accountability to Eden. If the Eden community agrees they can elect a new set of Chief Delegates on April 9th and this new set can approve the funding required to migrate Eden to a fully functional ƒractal.
What is ƒractally doing with Mandel?
ƒractally is developing a suite of next-generation DeFi standards, including a token standard, nft standard, premium name system, premium token symbol system, and decentralized exchange. These standards are required for ƒractally to realize its vision.
Furthermore, ƒractally has plans to build faster finality, support synchronous calls, and a key value database api. ƒractally has submitted a proposal to the EOS Network Foundation to build a minimal viable product including all new DeFi standards. We would charge 700,000 EOS for these system contracts. An additional 800,000 EOS will buy faster finality and synchronous calls.
Why does EOS require a new Token Standard?
The existing EOS token standard was designed around the “require_recipient” paradigm for handling deposits and withdrawals. This legacy design allows user contracts to abort transactions when a transfer is initiated. As a result, contracts dealing in tokens have had to implement a “deposit” / “withdraw” process. This creates “balance” tables in every contract. The result is code bloat and security vulnerabilities. A single math error or hack of a contract can drain all “balance” tables that contract is maintaining on behalf of its users.
Furthermore, self-governing DAOs have the power to upgrade their smart contracts at any time. This makes it impossible for them to make long-term commitments with respect to token inflation rates.
The new token standard will allow anyone to create a token, with or without a symbol. This will utilize a common contract account shared by all tokens. DAOs will receive call backs to override token behavior giving them full control over everything except increasing inflation beyond chosen limits.
The new deposit/withdrawal process will no longer utilize “require_recipient” because we feel this feature should be deprecated. It will move all the “credit” tables currently managed by every smart contract into the tokens contract. This will ensure that contracts can send and receive funds without worrying about notification handlers aborting their transactions.
Furthermore, every token will be uniquely identified with a 32 bit ID and can optionally be paired to a global Symbol registry. This greatly reduces RAM requirements for DeFi applications, ultimately reducing developer costs and further increasing the attractiveness of EOS as the premier DeFi platform
Why does EOS require a new NFT Standard?
Existing NFT standards are focused on “art” and “collectables” and are not suitable for the multitude of non-fungible assets with which one could want to interact with on a DeFi platform. Under the proposed NFT standard, NFTs are nothing more than a unique 64 bit number whose ownership can trade hands using an API similar to the new token contract.
Higher-level standards (e.g. AtomicAssets) can still be used to facilitate the creation and exchange of specific NFT assets. Ideally all higher-level standards would upgrade their smart-contracts to utilize our core NFT infrastructure in order to enjoy higher security and better interoperability for lower cost. To this end, it may be more appropriate to think of our proposed NFT standard as a “standard of standards.”
Premium Names, Symbol Names, Accounts, and token issuer permissions are 4 items that will leverage the new NFT system out of the gate. Anyone who wants to create a tradable bundle of permissions can utilize the new system.
Why does EOS require a new account naming system?
The 12 character names supported by EOS were never intended to be user facing. Instead, they were meant to be an implementation detail similar to how account numbers are an implementation detail on BitShares. They were made “human readable” by interpreting a 64 bit number as base32.
We propose making the existing account names an implementation detail and adopting longer 32 byte names. Furthermore, we propose adding a new 32 bit number to uniquely identify accounts. This will reduce RAM requirements for contracts and make faster database lookups as both names and tokens will be identified by 32 bit numbers. This allows an account/token pair to fit in a single 64 bit index.
The existing premium name auction is time consuming and frustrating for users. Names under our proposed system would have a “buy it now” price that automatically adjusts based upon demand.
What does the proposed token standard look like?
The following sequence diagram shows how a user Alice which goes by a 32 bit user number (u1) buys the token ticker symbol CAT and then issues a new fungible token type and assigns CAT to be the ticker symbol.
The lines represent actions or inline actions, the boxes represent smart contracts, and the dashed lines represent context-free-inline actions (aka events) sent to an account with no contact on them.
This diagram does not reflect the option for “auto-debit” which eliminates the need for Alice to claim the tokens sent to her.
You will note that two NFTs are created, one for the CAT symbol, and another for the issuer permission on the fungible tokens.
The following diagram shows how the new NFT standard can facilitate trading of accounts on any DeFi application that supports the new standard. This means that accounts, issuer permissions, symbol names, and premium account names can all be used as DeFi collateral.
How will the new standard impact existing token contracts?
We would provide a token bridge contract that would automatically and trustlessly allow anyone to migrate an existing token hosted by private contracts into a token managed by the new standard. Users would be able to seamlessly convert back and forth between the old and new standards.
Why do the block producers have to approve the new standards?
We feel that broad community support for the standard is key to its success and that accounts that start with ‘eosio.*’ are more trustworthy. The new account name buying system will require some updates to the existing system contract to avoid ambiguous collisions between the old and new way names are allocated. This will be critical for security.
Will this require updates to the /v1/ API and to other APIs?
The /v1/ API will forever be the /v1/ API. New APIs may be provided to simplify access. Enhancements to these APIs are not part of the proposed work.
Will this require updates to contract SDKs and client SDKs?
Anyone wanting to leverage the new tokens would want to utilize the new libraries in the new SDK.
How will this affect existing wallets?
Supporting the new standard will require all user interfaces to be aware of new actions, balance tables, and name/number registrations. ƒractally would provide a reference implementation of such an interface. Existing wallets and user interfaces who choose not to update will continue to be useful only for interacting with the legacy tokens, symbols, and names.
Is Eden on EOS a DAO?
Eden 1.0 is an organization that maintains a balance of EOS which is distributed among its members according to periodic elections. In the event the EOS tokens were lost contrary to the intent of the Eden members the organization would cease to have a budget. Accordingly, Eden 1.0 is not a DAO because it is not autonomous.
In the event Eden becomes a ƒractal, it will have its own token and become a fully autonomous DAO.
Is EOS a DAO?
The EOS network has its own transparent ledger and can be forked by the community in the event consensus can’t be reached. EOS leverages Delegated Proof of Stake and can be held accountable to the community opinion. Hive forking from Steem demonstrated how a truly decentralized and autonomous community based on DPOS can resolve governance disputes.
While EOS may be autonomous, its current governance structure is centralized in the EOS Network Foundation under Yves. Aside from Eden on EOS, budgeting decisions are being made in a centralized manner and the typical EOS user has no practical recourse if they disagree except to sell EOS.
EOS can adopt fully decentralized ƒractal governance to return power to the users of the platform and decentralize funding decisions.
原文链接/Original URL:
