Last month, we provided the first peak of our oracle Beta on Ethereum, and shortly after, on BSC. In case you missed it, check out the articles here and here, and see the oracle Beta in action here.
Following that, our community had a lot of questions — and rightly so! The oracle is a core piece of Phoenix Global moving forward, and below we provide the first batch of answers from our tech/dev team.
Note: Questions may not be presented verbatim and may be consolidated with other similarly relevant submissions.
Part 1: Phoenix Oracle
Q1. Can we expect to find other markets for data other than the Chinese? Though I understand that China is the main market how likely is it for the users to get data from outside Mainland China from the Oracle?
Yes, definitely, Greater China of course is one of the initial markets of focus because of our extended enterprise-user access and ecosystem we have there. Additionally, the data and AI ecosystem in China is very active and fast growing, with many opportunities in the areas of data-level collaboration, decentralized AI, and data exchange.
The decentralized oracle platform itself operates globally without any border or restrictions, in terms of user acquisition of who and where is more or less more contingent upon use case and data sources used. We will discuss our use case focus and differentiated value below.
Q2. What is the cost, or cost model, for a company to utilize PHB Oracle?
There is no start-up or minimum costs require to utilize the Phoenix Oracle. All they would need is a corresponding smart contract running on an EVM compatible VM, and costs-wise they would pay on a per-use basis using PHB. Net cost per usage would have two main components, being 1) oracle network cost 2) cost for data (if using data through our marketplaces such as DataX).
The benefit of having an oracle network as a part of Phoenix Chain, is that oracle use-cases have low barriers to usage and cost, contrary to full blockchain applications on a layer 1. It’s an easier way to bring partners into Phoenix’s ecosystem.
Q3. For Phoenix Chain to work; Oracles, Federated Learning or really any possible use case, the Layer-1 blockchain needs nodes (or supernodes). How is the team currently estimating the risk of current supernode candidates leaving the project because of the current lack of communication. Also, what is the team going to do to diminish this risk?
This is a very good point and an area that the team is putting substantial focus on. Over the past months, the team has been working hard to revamp the key technical components of our Layer 1 blockchain, in order to keep it up to date and competitive with the next wave of Web 3.0 growth. Certain technical plans and designs from the past simply do not make sense anymore (Data Cloud nodes, sidechains, etc), while other pre-supposed use cases (ie. Large scale consumer applications) are still distant in terms of actual adoption.
Instead, we are making optimizations to core infrastructure aspects of the project in-sync with both what the market needs as well as what we want to achieve, which includes but is not limited to:
- Layer 2 scaling and Layer 2 compatibility
- Layer 1 performance optimization, including revamped consensus (upon original DPOS)
- Technical features surrounding federated learning and MPC
Q4. In the Phoenix Oracle Medium article, it’s mentioned that randomized node selection has been chosen as a method because of advantages in decentralization. In this same paragraph; Federated Learning (Phoenix Chain) and Multi-party computation are mentioned. Federated Learning is a clear use case for PHB, but Multi-party computation only has been mentioned regarding our partnership with ARPA. Does this mean that ARPA will be using Phoenix Oracles? Or why is Multi-party computation an important use case for Phoenix Oracles?
Decentralized AI (federated learning) is one of the main use cases of Phoenix Chain, and multi-party-computation is a related use case, and sometimes these terms are used interchangeably. FL is able to deliver much larger variety of use cases than MPC, as well as being able to perform actual machine learning, as opposed to perform mainly simple statistical models or deterministic computation (which MPC can achieve). However MPC applications are often easier to implement on a technical level, with an easier result in mind (deterministic result, not predictive). ARPA’s technology stack and use cases are typically much more simpler than what Phoenix Chain has in plan/store. It would be correct to say that using Phoenix Chain in conjunction with Phoenix Oracle entirely encompasses ARPA’s scope.
Of course, ARPA, as with any other ecosystem partner is welcome to use our oracle service.
Q5. Is Phoenix Oracle developed and tested to serve as chain agnostic or is it fully BSC based?
It is developed to be a chain agnostic oracle, with the most in-depth and comprehensive integration with Phoenix Chain once mainnet launches. Currently it supports both Ethereum as well as BSC.
Q6. Why was the decision made to be a “chain-agnostic” Oracle platform? Doesn’t this cause PHB oracle nodes to get less rewards? By being chain-agnostic, Oracle costs will be split among many Layer-1 blockchains, instead of only Phoenix Chain.
An oracle being chain-agnostic is a very realistic and practical decision to maximize utility, ecosystem, and protocol value. Fees will all be paid in PHB, hence if users from more ecosystems use the oracle service than more fees will be generated than one that’s only single-chain compatible.
Q7. Will Oracle users be able to select a data source themselves? or can they only use the data source that has been selected by the oracle node?
Yes, they will be able to connect their own data sources, or alternatively they will be able to use connected data sources and those from DataX.
Q8. Will oracles for additional L1 blockchains, like Klaytn and Nervos, be already available on mainnet launch or is this something to be implemented later on? Also, considering that both Klaytn and Nervos were specifically named in the oracle beta release, is it safe to assume that there is a third party/parties that is currently building on those blockchains and is already planning to integrate Phoenix Oracle?
When we determine which Layer 1 platforms to integrate with Phoenix Oracle, we will likely consider it from a strategic and differentiation point of view. We are likely to consider a variety of factors, one of which being if a robust solution already exists for that blockchain ecosystem.
Q9. Are there any advantages of using Phoenix Oracle over oracles like Chainlink or Band Protocol *specifically* for DeFi?
For Phoenix Oracle, our main use case is not intended to be DeFi. DeFi utilizes mostly only price feeds, which is a simple data format with a multitude of data sources. We are focusing mostly on B2B data exchange, enterprise use cases, federated learning, MPC, and other more mission critical use cases of data verification, rather than for DeFi transactions and trading.
Q10. Considering that most of the piloting enterprises chose to go the private chain path, is it possible that they will be using the public Phoenix Oracle alongside their private chain deployments?
With the continued optimization of multi-chain and cross-chain technical solutions, enterprises using Phoenix Oracle along-side private chain and alliance chain deployments are no longer an issue, and can be implemented seamlessly.
That’s a wrap for Part 1 of our Q&A! Thank-you once again to all who submitted questions, and we are looking forward to providing the next batch.
